Menu
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?
469
Repeatable migrations have a description and a checksum, but no version. Instead of being run just once, they are (re-)applied every time their checksum changes. This is very useful for managing database objects whose definition can then simply be maintained in a single file in version control.
The hotfix migration can be deployed with Flyway with skipExecutingMigrations=true . The schema history table will be updated with the new migration, but the script itself won't be executed again. skipExecutingMigrations can be used with with cherryPick to skip specific migrations.
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.
120
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
