How to deal with changing Flyway migrations?

Question

I am currently investigating Flyway as an alternative to Liquibase, but was unable to find an answer to the following question in the documentation:

Assume a migration X is found to contain a bug after deployment in production. In retrospect, X should never have been executed as is, but it's already too late. However, we'd like to replace the migration X with a fixed version X', such that databases that are populated from scratch do not suffer from the same bug.

In Liquibase, you would fix the original changeset and use the <validChecksum> tag to notify Liquibase that the change was made by purpose. Is there a pendant to <validChecksum> in Flyway, or an alternative mechanism that achieves the same?

Answer 1

Although it is a violation of Flyway's API, the following approach has worked fine for us:

Write a beforeValidate.sql that fixes the checksum to match the expected value, so that when Flyway actually validates the checksum, everything seems fine.

An example:

-- The script xyz/V03_201808230839__Faulty_migration.sql was modified to fix a critical bug.
-- However, at this point there were already production systems with the old migration file.
-- On these systems, no additional statements need to be executed to reflect the change,
-- BUT we need to repair the Flyway checksum to match the expected value during the 'validate' command.
UPDATE schema_version
SET checksum = -842223670
WHERE (version, checksum) = ('03.201808230839', -861395806);

This has the advantage of only targetting one specific migration, unlike Flyway's repair command.

Answer 2

Depending how big the mess is you could also

• simply have a follow-up migrations to correct it (typo in new column name, ..)
• if that is not an option, you must manually fix both the migration and the DB and issue Flyway.repair() to realign the checksum http://flywaydb.org/documentation/command/repair.html