设置新基线后更改飞路迁移文件

Question

我在其中一个项目中集成了flyway。我有很多迁移，迁移新的空数据库需要很长时间，主要是因为在此过程中还添加了种子数据。现在我想改变它。不幸的是，这些迁移已经被推向生产（是的，在某些时候，种子数据也在那里迁移）。

我的想法是为当前版本的生产系统设置基线，然后清理旧的迁移：压缩模式迁移并将种子和测试数据移动到未部署到的新位置生产

现在我的问题是：

1. 如何在生产数据库中设置基线，而不影响所有其他基准？直接在数据库上调用flyway baseline ...？或者我可以使用任何类型的特殊迁移文件？也许将基线直接写入数据库的schema_version表？这样的查询怎么样？
2. 我最新的迁移是V4_6_3__...。所以我的基线需要在V5__...上？或者V4__...是否足够，并且包含所有具有相同主要版本的迁移？
3. 设置基线后，是否可以/保存添加，编辑和删除早于基线的迁移，而不会在下一次迁移任务中破坏生产数据库？

对不起基本问题，但在我看来，飞路文件根本没有帮助......

提前致谢！

Answer 1

谢谢迟到的回答。我对@markdsievers建议的那个做了类似的事情：

我确信生产环境至少是版本X（flyway.setTarget(X)）。然后我更改为新的架构版本表（flyway.setTable('temporary_schema_version')）并运行了一次删除旧表的迁移。之后我将架构版本表更改回原始版本，将基线设置为版本Y > X并运行另一个删除临时表的迁移。

现在，我可以编辑/压缩/删除版本低于Y的所有迁移，而不会导致生产部署崩溃。

Answer 2

我经历了一个非常类似的场景，甚至编写了我们自己的内部工具，名为“Rebaser”，它可以完成您想要的大部分工作。我们的主要动机是从Flyway 3.x升级到4.3但我们也有一个需要被压扁的大历史。它的要点是：

1. 将所有迁移工作都压缩，然而许多迁移都是有道理的。我通常有一个V2__base_ddl.sql和V3__base_data.sql（Flyway可以使用前几个版本号进行模式创建等）。这是手册部分。
2. 您的rebase工具会检测旧的schema_version表并删除它。
3. 然后，您的rebase工具会运行init + migrate并设置新的基线版本。
4. Rebase工具留下了一个足迹（自定义表中的一个rebase键），表明它已经完成。

对于我的集成测试版本（启动vanilla数据库并向前迁移到最新版本）我使用Flyways locations参数添加了一个额外的测试数据SQL脚本文件夹，从而确保我有集成测试的测试数据但是不在任何非测试环境中。

我们的Rebaser只是Flyway Java API的一个薄包装器，如果已配置，则添加预处理以执行rebase，然后委托给Flyway。

Flyway没有变基的概念，但是当你的历史变得庞大并且包含过时的数据/ DDL时，我们发现它是必要的。到目前为止，这个系统运作完美。