development:database_migration_management
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
development:database_migration_management [2015/04/24 13:08] lee [Create idempotent database migration scripts] |
development:database_migration_management [2015/04/24 13:18] (current) lee [How the OHDSI WebAPI services use Flyway] |
||
|---|---|---|---|
| Line 38: | Line 38: | ||
| Note. The OHDSI WebAPI build has the Flyway "out of order execution" option enabled so that the rules around database script execution order are relaxed. This provides needed flexibility when we have typically one developer working on each subset of WebAPI services. Since we want to enable each developer to be able to work independently in parallel, this approach avoids the more complex alternative of requiring separate forks for WebAPI database migrations. | Note. The OHDSI WebAPI build has the Flyway "out of order execution" option enabled so that the rules around database script execution order are relaxed. This provides needed flexibility when we have typically one developer working on each subset of WebAPI services. Since we want to enable each developer to be able to work independently in parallel, this approach avoids the more complex alternative of requiring separate forks for WebAPI database migrations. | ||
| + | |||
| + | When the Flyway "out of order execution" option is enabled, it means that newly created scripts will also be run (the first time flyway encounters them) even if their version numbers are lower than the highest previously executed version number. | ||
| + | |||
| + | For the OHDSI WebAPI having this option enabled gives us the flexibility for one developer to e.g. add a new database migration script V1.0.0.1.1_heracles_schema_migration.sql and it will be executed one time, even if the last previous version change was V1.0.0.4_circe_schema_migration.sql. i.e. It allows each developer to flexibly & independently migrate their database tables for the set of WebAPI services they are responsible for, without schema change conflicts, as long as those sets of tables are distinct from the tables used by other WebAPI services. | ||
| ==== Testing Flyway migration scripts prior to a pull request ==== | ==== Testing Flyway migration scripts prior to a pull request ==== | ||
| Ideally you will need access to a local test environment with all three DBMS systems - SQL Server, Postgresql and Oracle. Build a copy of the WebAPI locally with whichever database profile you are most familiar with using. Flyway will then automatically execute the database migration script according to your maven build settings and you will see the tables are automatically created in your database. You can then manually test the database scripts for the other DBMSs by manually running them in a matching local DBMS to ensure they execute as expected. | Ideally you will need access to a local test environment with all three DBMS systems - SQL Server, Postgresql and Oracle. Build a copy of the WebAPI locally with whichever database profile you are most familiar with using. Flyway will then automatically execute the database migration script according to your maven build settings and you will see the tables are automatically created in your database. You can then manually test the database scripts for the other DBMSs by manually running them in a matching local DBMS to ensure they execute as expected. | ||
development/database_migration_management.txt ยท Last modified: 2015/04/24 13:18 by lee
Page Tools
