Repair: update checksums after migration

[ben-manes]

When using checksum validation, it is tedious to update the checksum when valid changes had to be made to run migrations. This can be done manually, but as the number of databases grow it promotes disabling this useful feature due to the manual work involved.

A few examples,

• Migrating MySQL to strict mode requires fixing tables (e.g. multiple timestamps) and queries (e.g. group-by). A database in strict mode can't apply older migrations, so it makes sense to patch environments over manually and change old migrations.
• Developers sometimes hard code the production schema name to their scripts, instead of letting Flyway handle that namespacing. When adding the feature to make the target schema a dynamic configuration, e.g. for tests, this breaks.
• Incorrect line endings affect the checksum (easy to fix in build after observed)

We'd want validation to fail by default to determine if the change is safe. For example developers have tried to get away with changing data type after a migration, e.g. varchar(20) to varchar(40), instead of making a new migration step.

Being able to catch and accept or reject script changes is beneficial, but accepting them appears to currently require that we manually update the schema version table.

[axelfontaine]

Hi Ben,

Thanks for the suggestion and sorry for the delay. I see where you are coming from. I am currently unsure how to address this. It is not an exact fit for the current semantics of repair.

Cheers
Axel

[cvillemure]

I would love that feature too, I currently have the same problem where I want to fix an old script for future database initialization but I don't need to run them on existing databases