2

这是一个艰难的。

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

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

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

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

  • 我不能强迫我的客户应用最新的补丁。
  • 我不能强迫开发人员避免这种情况。

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

4

3 回答 3

3

我想这类问题更具组织性，而不是特定于工具的。如果您支持多个版本（一个分支 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 版本的升级过程中。

于 2013-05-14T10:00:36.337 回答
2

Liquibase will handle the drop index change across branches fine, but since you are going from a version that contains code (a drop index change) to one that does not expect that you are going to end up with your broken app state.

With liquibase, changes are completely independent of each other and independent of any versioning. You can think of the liquibase changelog as an ordered list of changes to make that each have a unique identifier. When you do an update, liquibase checks each change in turn to see if it has been ran and runs it if it has not.

Any "versioning" is purely within your codebase and branching scheme, liquibase does not care.

Imagine you start out with your 1.1.0 release that looks like:

  • change a
  • change b
  • change c

when you deploy 1.1.0, the customer database will know changes a,b, and c were ran.

You have v2.1 with new changesets to the end of your changelog file, so it looks like:

  • change a
  • change b
  • change c
  • change x
  • change y
  • change z

and all 2.1 customers database know that a,b,c,x,y,z are applied.

When you create 1.1.0.1 with changeset d that drops your index, you end up with this changelog in the 1.1.0.1 branch:

  • change a
  • change b
  • change c
  • change d

But when you upgrade your 1.1.0.1 customers to 2.1, liquibase just compares the defined changesets of (a,b,c,x,y,z) against the known changesets of (a,b,c,d) and runs x,y,z. It doesn't care that there is an already ran changeset of d, it does nothing about that.

The liquibase diff support can be used as a bit of a sanity check and would be able to report that there is a missing index compared to some "correct" database, but that is not something you would normally do in a production deployment scenario.

于 2013-05-16T18:34:16.927 回答
0

答案可能有点晚，但我会分享我的经验。我们在项目中也遇到了同样的问题。我们通过以下方式处理它：

由于我们项目中的版本不经常发布，我们在 liquibase 特定上下文中标记了每个变更集。该值是确切的版本迁移（如v6.2.1-v6.2.2）。我们通过 jndi 属性将值传递给 liquibase，因此客户可以指定它们。因此，在升级期间，客户负责为每次升级的迁移范围设置正确的值。Liquibase 上下文可以接受值列表。所以最后，上下文看起来像这样：

context=v5.1-5.2,v5.3-5.3.1,v5.3.1-5.4,v6.2.1-v6.2.2
于 2016-08-23T16:03:15.693 回答