我一直在关注Flyway作为数据库迁移工具。
我无法找到明确答案的一件事是：
我是否可以强制Flyway在单个事务中运行所有尚未应用的迁移，而不是让每次迁移成为自己的事务？
在开发环境中，这不是问题，但在生产环境中，您可能会从一个更新到下一个更新执行多次迁移，其中一个迁移失败会使数据库处于“半迁移”状态，其中一些迁移已经发生，一些不是 - 非常糟糕。
解决方法是简单地填写单个文件中所需的所有SQL，但是存在以下问题：
生产迁移和dev迁移最终会以不同的方式执行，因为您无法事先知道在dev环境中迁移的内容。我想你总是可以做一个干净的，然后是一个新的迁移，但这似乎违背了飞路设计关于增量迁移的精神。
添加新更改后，校验和会有所不同。
Flyway仍然不支持这样的功能吗？是Liquibase还是其他任何迁移工具？
答案 0 :(得分：2)
没有开箱即用的功能。这是一个很好的问题但是我敢打赌，因为Flyway提供了每次迁移的事务边界，所以我认为Axel Fontaine会引起技术/设计方面的考虑，导致这不是特征。
常见问题解答有关于降级/失败的this和this。该政策归结为：
保持数据库与所有版本之间的向后兼容性 目前在生产中部署的代码....经过了充分的测试， 备份和恢复策略。
就我而言，我们已经使用Flyway将近3年并且已经遵守所引用的政策。在任何给定的部署中，我们可以针对许多数据库运行100次或更多次迁移，并且很高兴地说在生产中从未发生过任何不幸事件。这一切都归结为最大限度地减少发布过程中失败的机会。
之前我在一个小得多的项目中使用了Liquibase，并且除了提供回滚程序之外，不记得任何这样的功能。