2

これは難しいものです。

  1. v1.1インデックス i のテーブルがあります。
  2. v2.1このテーブルとインデックスも含まれています。

バグが発見されv1.1.0.1、コードを変更した結果、インデックスを削除することにしました。
に対応するパッチを作成しましv2.1たv2.1.0.6。

お客様がパッチを適用し、数週間後に(パッチ 6 なし)v1.1.0.1にアップグレードしました。v2.1

コードベースはインデックスを使用するとパフォーマンスが向上するためv2.1、「壊れた」アプリケーションになります。

  • 顧客に最新のパッチを適用するよう強制することはできません。
  • 開発者にそのようなシナリオを避けるよう強制することはできません。

Liquibase または Flyway はこのシナリオを処理できますか?

4

3 に答える 3

2

Liquibase はブランチ全体でドロップ インデックスの変更を適切に処理しますが、コードを含むバージョン (ドロップ インデックスの変更) から、壊れたアプリの状態になることを想定していないバージョンに移行するためです。

liquibase を使用すると、変更は互いに完全に独立しており、バージョン管理からも独立しています。liquibase の変更ログは、それぞれが一意の識別子を持つ変更の順序付きリストと考えることができます。更新を行うと、liquibase は各変更を順番にチェックして、実行されているかどうかを確認し、実行されていない場合は実行します。

「バージョン管理」は純粋にコードベースと分岐スキーム内にあり、liquibase は気にしません。

次のような 1.1.0 リリースから始めると想像してください。

  • 変更する
  • 変更 b
  • 変更 c

1.1.0 を展開すると、顧客データベースは、変更 a、b、および c が実行されたことを認識します。

変更ログ ファイルの最後に新しい変更セットを含む v2.1 があるため、次のようになります。

  • 変更する
  • 変更 b
  • 変更 c
  • ×を変える
  • y を変更
  • z を変更

すべての 2.1 顧客データベースは、a、b、c、x、y、z が適用されていることを認識しています。

インデックスを削除する変更セット d を使用して 1.1.0.1 を作成すると、1.1.0.1 ブランチに次の変更ログが作成されます。

  • 変更する
  • 変更 b
  • 変更 c
  • かわった

しかし、1.1.0.1 の顧客を 2.1 にアップグレードすると、liquibase は (a,b,c,x,y,z) の定義済み変更セットを (a,b,c,d) の既知の変更セットと比較し、x を実行します。 y、z。すでに実行されている d の変更セットがあることは気にしません。それについては何もしません。

liquibase diff サポートは、ちょっとしたサニティ チェックとして使用でき、「正しい」データベースと比較してインデックスが欠落していることを報告できますが、これは本番環境の展開シナリオでは通常行うことではありません。

于 2013-05-16T18:34:16.927 に答える