職場のアプリケーション用にフライウェイプロジェクトを作成しました。テストの準備が整う前に、開発者の一人がすでにTESTでいくつかのSQL文を実行していました。flyway:SQL文が失敗してもマイグレーションを強制する
ALTER TABLE "TABLE1" MODIFY ("NAME" VARCHAR2(75 CHAR));
ALTER TABLE "TABLE2" DROP ("BOARD_ID");
ALTER TABLE "TABLE3" ADD CONSTRAINT "SYS_C0022270" CHECK ("ID" IS NOT NULL) ENABLE;
文#2にドロップする必要があるカラムは、すでに我々のテストインスタンスに手動で削除されました:
私のSQLスクリプトは、いくつかの文を持っています。私たちのPRODインスタンスにはドロップされていません。私は手動ではなくマイグレーションによってそれをやりたいのです。
明らかに、私はPROD上でTESTを最初に試してみることはありません(これらの3つのクエリよりも多くのことがあります)。
しかし、私が問題を抱えている移行が最初の行であるため、続行できません。
強制する方法はありますか?私はその列が既に削除されていることを知っています。私はそれをもう一度作成して、マイグレーションでそれを削除することができます。しかし、私は失敗する可能性がある行の下に他のクエリがあるかもしれません(すでに存在する可能性のあるシードデータの作成など)。そして私はそれが私たちの展開を止めることを望んでいません。
私たちのDBをPRODから再度クローンし、開発チームが開発を中止して新しい移行セットを準備する以外のアイデアはありますか?
シード・データの競合の例を示します。データベースに格納されているジャスパー・テンプレートを指すオブジェクトがいくつかあります。複数のレコードがそのテンプレートを指しています。各オブジェクトのSQLスクリプトには、テンプレートが存在しない場合に作成するためのクエリがあります。 (開発の時点で、どのオブジェクトが先に展開されるのかは不明であったため)。最初のスクリプトが実行された後、既に挿入されているため、実際には気にしない単一のクエリが原因で他のすべてのスクリプトが失敗します。 – robertrv
私は各ファイルからクエリを削除し、それを独立したスクリプトにする必要があることを知っています。しかし、失敗したクエリを無視する方法も有効でした。さて、私たちのユニークな必要性のためにこのような機能を実装することはお勧めしません。似たようなものがあるのかどうか疑問に思っていただけです。 – robertrv
これは落とした列とは何が関係していますか?それとも、これは多くの人の中の一例ですか? –