如何使用Flyway处理新的中间迁移

Question

我最近发现了Flyway，在阅读和搜索时，我遇到了以下博文：Database schema evolution versus schema versioning。

所以我想知道：

• 它说的仍然是真的（当时甚至是真的）
• 使用flyway时如何处理这种情况。

编辑：

常见问题解答简要介绍了this（没有为上述问题提供解决方案）。

Answer 1

我不能多说dbdeploy，但关于flyway的陈述是正确的。 Flyway对处理SQL脚本非常严格：

• 每个脚本只部署一次，并且必须具有比以前部署的所有脚本都更高的版本号（因此历史上无法回溯）
• 已部署的脚本不能再修改

这种严格性并不是一件坏事，但是开箱即用的方案不支持引入数据库修改的几个代码分支。

我们在这种情况下使用flyway，但我们必须做一些解决方法。首先，我们将所有SQL脚本分为两组：已经在生产中的脚本和不在生产中的脚本。可以随时修改所有未生产的脚本（无论它们位于哪个分支上）。为了支持这一点，我们编写脚本的方式可以根据需要经常执行。其次，我们介入flyway的簿记，这是在一个名为SCHEMA_VERSION的表格中完成的。在每次飞行路线迁移之前，我们会删除所有尚未投入​​生产的条目。在开发系统上启动迁移时，flyway将每次执行所有新脚本。但是，在生产系统上，新脚本在它们上线时只执行一次。