Database migrator

Overview

One of the main framework ideas is to isolate modules form each other. To implement this idea it was decided that each module should provide methods to install/uninstall it in the web-site. Part of the module install process is creating required database structure and filling it. Each module provide list of changes (migrations) that should be implemented in the database for it correct work. This solution is based on ECM7 Migrator library.

Problem

Default application of ECM7 Migrator is to provide mechanism of versions to DB, i.e. if we can versions 1000, 2000 and 3000 the database structure can be change to any of this versions. Current database migrations are stored in SchemaInfo table. But in our case we have an independent module architecture, where each module can provide own versions of database.Let's see the example:

• Module A has 3 migrations: 1000, 3000, 5000.

• Module B has 1 migrations: 4000.

• Administrator of web-site decided to install module B. So current version of the database will be 4000. After that administrator decided to install module A. But in process of installation only migrations with versions upper than current will be executed. So migrations 1000 and 3000 will be skipped.

Solution

To resolve described problem was decided to create additional database table (Migrations), where migration versions of each module will be stored.

Module installation

• Delete all records from SchemaInfo table.
• In Migrations table find all migrations of the current module that have been already executed.
• Copy founded versions to SchemaInfo table.
• Execute all module migrations.
• Insert all executed migrations to Migrations table.

Let's return to our example. Administrator installed module B. So in SchemaInfo it will be only one version 4000. The same version will be in Migrations table (and it will be linked to module B). Let's see process of installation module A according to the algorithm:

• Schema info is empty.
• There are no migrations of module A in the database.
• Do nothing.
• Current database version is NULL, so all migrations of module A (1000, 3000, 5000) will be executed.
• Insert versions 1000, 3000, 5000 to the Migrations table and link it to module A.

Module uninstallation

• Delete all records from SchemaInfo table.
  

• In Migrations table find all migrations of the current module that have been already executed.
  

• Copy founded versions to SchemaInfo table.
  

• Execute all module revert migrations.
  

• Delete all executed migrations from Migrations table.
  

Implementation

Described algorithm is implemented by CoreMigrator class. It has to public methods:

public void MigrateUp(ICorePlugin plugin)

public void MigrateDown(ICorePlugin plugin)

Both methods take ICorePlugin as an input parameter. It is a module that should be installed (method MigrateUp) or uninstalled (methods MigrateDown).