liquibase - Liquibase 或 Flyway 能否处理多非线性版本控制场景？

Question

这是一个艰难的过程。

1. v1.1 有一个索引为 i 的表。
2. v2.1 也包含此表和索引。

我们发现了一个错误，在 v1.1.0.1 中我们更改了代码，因此决定删除索引。
我们为 v2.1、v2.1.0.6 创建了相应的补丁。

客户应用了补丁 v1.1.0.1，几周后升级到 v2.1(没有补丁 6)

由于 v2.1 代码库在索引方面表现更好，我们有一个“损坏的”应用程序。

• 我不能强制我的客户安装最新的补丁。
• 我不能强制开发人员避免这种情况。

Liquibase 或 Flyway 可以处理这种情况吗？

Answer 1

我想这类问题更多是组织性的，而不是特定于工具的。如果您支持多个版本(分支 1.0 和更新的 2.0)并为两者提供补丁(这是完全合法的方法 - 不要误会我的意思)您可能必须为所有这些版本提供升级说明，也许显示您可以从哪个版本转到哪个版本(以及您不能做什么)的矩阵。

我刚好升级了 Atlassian 的 Jira Bugtracker 的旧版本，不得不发现他们确实提供了所有版本的升级说明。

这意味着从一个版本转到下一个版本，最终到达最新版本(我当时使用的是 4.x 版本，想转到最新的 5.x)并遵守其间的所有升级说明。 (顺便说一句，我跳过了所有这些并将其设置为全新安装以避免这种情况。)

为了给您一个印象，这里有一个页面显示了所有这些升级说明: https://confluence.atlassian.com/display/JIRA/Important+Version-Specific+Upgrade+Notes

所以我猜你可以提供一个小脚本来重新创建索引，如果有人想从版本 1.1.0.1 开始的话。至 2.1并在升级说明中声明需要应用它。

既然你问 liquibase(或 flyway)是否可以支持这个，也许提及 liquibase(我只知道 liquibase)有一个叫做 preConditions 的东西可能会有所帮助.这意味着您可以根据(例如)索引存在的事实运行变更集(resp. sql) <indexExists> .

如果索引丢失，这可能有助于重新创建索引。

但由于 2.1 版本已经发布(在知道索引可能会在未来的错误修复中被删除之前)，因此没有机会将此功能添加到 2.1 版本的升级过程中。