We have a system in production where we use Flyway for db migrations.
Initially it was developed to run on MySQL 5.5 and later on some of our customers have upgraded to 5.6 and then to 5.7.
There is a change in MySQL 5.7 compared to 5.6 - datetime fields defined as NOT NULL must have a default value in the SQL script for 5.7 - whereas in 5.6 it was allowed to not have a default value.
So we have a migration that does this in v11 but in v2 there is a migration that uses the (now in 5.7) illegal syntax without a default value.
So if we try to install on an empty Mysql 5.7 database the Flyway migration will fail at step 2.
If we change the v2 migration to have the default value so a fresh install on 5.7 succeeds the checksum won't match if we run the migration on an existing installation that have already migrated v2 once.
What is the 'nice and clean' way to deal with this issue?
I was thinking about using Flyway baseline for the fresh installations on 5.7 to skip the steps we know will fail on the 5.7 and then have a separate bootstrap script that sets up the schema like v1 and v2 would have done, before we run the flyway baseline.
If there is a better way to handle this situation and support both scenarios I would very much like to hear about it.
Use Flyway's repair command to realign the checksums in the 5.6 DB with the ones on disk once you have made the change.