【发布时间】：2020-12-14 23:14:38
【问题描述】：
在测试对 Postgres 数据库的升级时，我们发现我们最旧的版本化迁移文件之一不再是有效的 SQL。这对于生产数据库来说不是问题，它（当然）已经在 schema_history_table 中进行了这些迁移，但是这个损坏的 V 文件现在无法建立任何新的沙箱。
在不永远孤立我们的生产数据库的情况下，将旧 V 文件带入现代世界的最佳方法是什么？
【问题讨论】：
标签： postgresql flyway
【发布时间】：2020-12-14 23:14:38
【问题描述】：
我能想到几个可能的选择。
- 配置 postgres 以启用以前版本的兼容性。我不是这方面的专家，但我认为有some options here。
- 只需将历史迁移脚本修改为现在可以与新版本一起使用。这意味着你不能再忍受旧版本了，但这对你来说重要吗？我认为您需要在执行此操作后运行 Flyway 修复，因为 Flyway 会检测到文件已被篡改。
- 创建一组并行脚本，每个版本一个，将它们放在不同的文件夹中。然后使用 flyway.locations 选项根据目标的版本指定不同的文件夹。
【讨论】：
-
选项 2 是最“Flyway”的选项。 Flyway 修复允许您在进行本地更改时更新架构历史记录（出于此类原因）。
-
谢谢！我希望我们在这里选择选项 2 并运行
flyway repair。过去我们在编写迁移时没有从树中看到森林（我记得在两个 V 文件之间重用临时表的名称而不将其丢弃在它们之间，从而破坏了新数据库）。