Best practice: How to modify flyway migration script after it has been used

19
votes

I am looking for an advice in the following case.

I set up flyway migration scripts in my production environment. On every deployment the database will be migrated to the current version. I already have created several migrations scripts which have been applied to the production database.

Recently I upgraded my development MySQL tools which now include warnings about usage of deprecated functions and other warnings. These warnings have not been displayed in the older version. Of course I would like to fix the warnings, especially for the case when a future version of the database does not support the deprecated functions any more. But the migrations containing the warnings have already been deployed and used. If I change one of the scripts there is a flyway warning:

ERROR: Validate failed. Migration Checksum mismatch for migration 2.0
-> Applied to database : 1778293504
-> Resolved locally    : 1831545539

I could change the checksum which is stored in the database to migrate, but that does not sound like a "good" way to do it. What is the common way / best practice to change a migration script after it has already been used?

2
flyway

2 Answers

23
votes

The first rule is don't.

The second one is do it very carefully and use Flyway.repair() to realign the checksums in the DB with the ones on disk.

3
votes

I completely agree with the fact you shouldn't do it.

But if you really need to, you can change the flyway configuration and set the validateOnMigrate boolean as false.

Here's the link: https://flywaydb.org/documentation/commandline/migrate#validateOnMigrate