Question

I just recently found out about Flyway and while reading and searching about it I ran into the following blog post: Database schema evolution versus schema versioning.

So I was wondering:

• Is what it says still true (or even true at the time)
• How should such a case be handled while using flyway.

Edit:

The FAQ briefly talks about this (without giving a solution for the afore mentioned problem).

Answer 1

I can’t say much about dbdeploy but the statements about flyway are correct. Flyway is extremely strict about handling SQL scripts:

• each script is deployed only once and must have a higher version number than all previously deployed scripts (so there is no way back in history)
• a deployed script cannot be modified anymore

This strictness is not a bad thing but scenarios like having several code branches that introduce database modifications are not supported out of the box.

We are using flyway in such scenarios but we have to make a few workarounds. Firstly, we divide all SQL scripts into two groups: the scripts that are already in production and the scripts that aren’t. All scripts that are not in production (no matter on which branch they are) can be modified at any time. To support this, we write the scripts in a way that they can be executed as often as needed. Secondly, we intervene in flyway’s bookkeeping that is done in a table called SCHEMA_VERSION. There we remove all entries that are not yet in production before each flyway migration. When the migration is initiated on a development system, flyway will execute all new scripts each time. On the production system, however, the new scripts are executed only once at the time when they go live.