1

私は最近Flywayについて知り、それを読んで検索しているときに、次のブログ投稿に遭遇しました:データベーススキーマの進化とスキーマのバージョン管理

だから私は疑問に思っていました:

  • それがまだ真実である(またはその時点でさえ真実である)と言っていることですか
  • フライウェイを使用している間、そのようなケースはどのように扱われるべきですか。

編集:

FAQはこれについて簡単に説明しています(前述の問題の解決策は提供していません)。

4

1 に答える 1

3

dbdeploy についてはあまり言えませんが、flyway に関する記述は正しいです。Flyway は、SQL スクリプトの処理に関して非常に厳格です。

  • 各スクリプトは一度だけ展開され、以前に展開されたすべてのスクリプトよりも高いバージョン番号を持つ必要があります (したがって、履歴を遡ることはできません)。
  • デプロイされたスクリプトは変更できなくなりました

この厳格さは悪いことではありませんが、データベースの変更を導入する複数のコード ブランチがあるようなシナリオは、そのままではサポートされていません。

このようなシナリオではフライウェイを使用していますが、いくつかの回避策を講じる必要があります。まず、すべての SQL スクリプトを 2 つのグループに分けます。既に運用されているスクリプトと運用されていないスクリプトです。本番環境にないすべてのスクリプト (どのブランチにあるかに関係なく) はいつでも変更できます。これをサポートするために、必要に応じて何度でも実行できるようにスクリプトを作成します。次に、 と呼ばれるテーブルで行われるフライウェイの簿記に介入しますSCHEMA_VERSION。各フライウェイ移行の前に、まだ本番環境にないエントリをすべて削除します。開発システムで移行が開始されると、flyway は毎回すべての新しいスクリプトを実行します。ただし、本番システムでは、新しいスクリプトはライブになるときに 1 回だけ実行されます。

于 2012-08-08T21:03:47.887 に答える