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

Question

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

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

现在我的问题是：

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

很抱歉的基本问题，但在我看来，那飞路文档是没有帮助...

提前感谢！

Answer 1

Sry为已故的答案。我已经做了一个非常类似的事情@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. 您的重新组合工具会检测旧的schema_version表并将其删除。
3. 然后，您的基准工具将使用新的基准版本集运行init + migrate。
4. 重做工具留下足迹（自定义表格中的重新键），表明它已完成。

对于我的集成测试构建（即旋转了一个香草数据库，并迁移转发到最新的）我添加使用飞行路线locations参数测试数据的SQL脚本的一个额外的文件夹，从而保证我有测试数据，集成测试，但不在任何非测试环境中。

我们的Rebaser只是一个围绕着Flyway Java API的薄包装，在pretep中添加了如果已配置然后委托给Flyway的rebase。

Flyway没有rebasing的概念，但是我们发现这是我们发现的必须做的事，因为您的历史变得很大并且包含过时的数据/ DDL。到目前为止，这个系统工作完美无瑕。