FAQ Flyway

https://flywaydb.org/documentation/faq

What is the best strategy for dealing with hot fixes?

You have a regular release schedule, say once per sprint. Version 7 is live and you are developing version 8. Version 8 contains DB Schema Changes. Suddenly hot fix is required for version 7, and it also needs a schema change.

How can you deal with this?

Even though the code may be branched, the database schema won't. It will have a linear evolution.

This means that the emergency fix, say version 7.1 needs to be deployed as part of the hot fix AND the new version 8.

By the time等到 version 8 will be deployed, Flyway will recognize that the migration version 7.1 has already be applied. It will ignore it and migrate to version 8.

When recreating the database, everything with be cleanly installed in order: version 7, 7.1 and 8.

If this isn't an option you can activate the outOfOrder property to allow Flyway to run the migrations out of order and fill the gaps.

Can I make structure changes to the DB outside of Flyway?

No. One of the prerequisites for being able to rely on the metadata in the database and having reliable migrations is that ALL database changes are made by Flyway. No exceptions. The price for this reliability is discipline纪律. Ad hoc 特别的changes have no room here as they will literally sabotage妨害 your confidence. Even simple things like adding an index can trip over a migration if it has already been added manually before.

How do you repair the database after a failed migration?

If your database supports DDL transactions, Flyway does the work for you.

If your database doesn't, these are the steps to follow:

1. Manually undo the changes of the migration
2. Invoke the repair command
3. Fix the failed migration
4. Try again

Why is the flyway_schema_history table case-sensitive?

The flyway_schema_history is case-sensitive due to the quotes used in its creation script. This allows for characters not supported in identifiers otherwise.

The name (and case) can be configured through the flyway.table property.

The table is an internal Flyway implementation detail and not part of the a public API. It can therefore change from time to time.