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?
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.