如何应对不断变化的 Flyway 迁移？

Question

我目前正在调查迁飞作为替代Liquibase，但无法找到答案的文档中的以下问题：

假设X在生产中部署后发现迁移包含错误。回想起来，本X 不应该按原样执行，但已经太晚了。但是，我们想X用固定版本替换迁移X'，这样从头开始填充的数据库就不会遇到相同的错误。

在 Liquibase 中，您将修复原始变更集并使用<validChecksum>标记通知 Liquibase 更改是有意为之。<validChecksum>Flyway 中是否有吊坠，或实现相同目的的替代机制？

Answer 1

虽然这违反了 Flyway 的 API，但以下方法对我们来说效果很好：

编写一个beforeValidate.sql修复校验和以匹配预期值的代码，这样当 Flyway 实际验证校验和时，一切看起来都很好。

一个例子：

-- 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);

与 Flyway 的命令不同，这样做的优点是只针对一个特定的迁移repair。