Using flyway with distributed source-code management (i.e. Git, Mercurial, etc...)

1
votes

I'm a part of a large java project with multiple modules (30 or so jars) and am interested in the use of flyway to manage database migrations.

As a part of company policy, migration scripts related to each project live in each module and at migration time are aggregated to form one large sql script from release --> release. (e.g. build 234 --> 298). also worthy of noting is that we currently use CVS (obligatory -_- face) and are looking at git as a replacement :).

due to Git's distributed nature, It is counter-intuitive to think of sequential version numbers for naming flyway migration scripts. let me digress further...

Scenario

  • A user branches off master A onto his feature branch B
  • A seperate user branches of A to their own feature C
  • Someone commits a script to B. Lets call it script 1
  • Someone else commits a script to C. script 2
  • At some point these changes are brought into the master branch

And now if you can't already see the problem, the order in which these changes are brought into master is arbitrary. the developers cannot version their scripts appropriately (assuming that no communication is done in regards to commit order amongst the team). script 2 could be brought in at some point, migrated, then later script 1 is brought in and placed before script 2' file in terms of flyway script versions.

Question

How does Flyway manage "inserted" scripts when the database has already migrated past them?

This is one of my only concerns in moving the current system into using flyway and any insight/help would be appreciated.

1
gitdatabase-migrationflyway

1 Answers

2
votes

According to this blog, Flyway ignores out-of-order migrations (i.e. it only migrates files past the most recent version that has migrated). however, the flyway.outOfOrder property may be set to true to enable a work around for this ordering problem.

flyway.outOfOrder=true

Another useful tip is that instead of using incremental integers for versions, use Timestamps. The more precise the Timestamp, the less chance of a version collision.

e.g.

20140707.154401__create_customer_table.sql
20140707.154402__alter_customer_table.sql