Monday, October 9, 2017

Use Flyway to manage the schema change

Upgrade the database is challenging.  Data may be already there while you are introducing the schema change.

The base schema may be different.  New customers start from scratch with an empty database.
Existing customers may be at the different patching levels and thus require different "ALTER script" to change the schema.

Flyway is not the most advanced system I have seen and it does meet all my expectations, but it is a helpful tool to manage this schema migration problem.


Flyway does one very basically thing.

It has a table called schema_version.

When it runs a database update script with a version, it stores the version number there in the database.

Next time, it checks if a version of the script has been applied in the database.  If it does, it skips the older versions and start with a newer versions.

Here are the design assumptions of using flyway:

It uses naming conversion to determine the version.  Some tools use repository and it does not need a separate repository.  It makes uptaking flyway very easy.

It assumes that the "Delta" are included in the files with version number.  Coding the delta is possible but difficult.  I always feel that delta should be generated by a tool by comparing the original to the target.

It assume that the delta will be applied on top of the other in a sequence.   The file does not include a full image and thus it is taking a "hop" based approach.




No comments: