1

仕事中のアプリケーション用に flyway プロジェクトを作成しました。結局のところ、開発者の 1 人は、フライウェイのセットアップをテストする準備が整う前に、すでに TEST で SQL ステートメントの一部を実行していました。

私の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 で削除する必要がある列は、TEST インスタンスで既に手動で削除されています。私たちの PROD インスタンスにはドロップされていません。手動ではなく、移行によってドロップしたいと考えています。

明らかに、最初に TEST で試してみずに PROD で移行を実行しているわけではありません (これらの 3 つのクエリよりも多くのものがあります)。

しかし、私が問題を抱えている移行は最初の行であるため、続行できません。

強制的に通過させる方法はありますか？列が既に削除されていることは知っています。もう一度作成してから、移行で削除することができます。しかし、失敗する可能性のある他のクエリがある可能性があります (既に存在する可能性のあるシード データの作成など)。そして、私たちの展開を止めたくありません。

PROD から DB を再度複製し、新しい移行セットを準備している間、開発チームに開発を停止させる以外のアイデアはありますか?

4

4 に答える 4

5

エラーを無視したい SQL ステートメントは、例外ハンドラーを使用して PL/SQL ブロック内に配置できます。

BEGIN 
  EXECUTE IMMEDIATE 'ALTER TABLE "TABLE1" MODIFY ("NAME" VARCHAR2(75 CHAR))';
EXCEPTION
  WHEN OTHERS THEN
    -- perhaps print a message about the command failure here
END;
/

DDL は、PL/SQL 内の即時実行ステートメント内で実行する必要があります。

少し痛いですが、うまくいくはずです。

于 2012-05-08T17:21:44.470 に答える
1

その音からすると、柱を再作成することが最善の解決策のように思えます。

それは非常に単純で、唯一の目的がカラムを直後に再びドロップすることである場合、まったく無害です。

ストーリーの一部を見逃していない限り、シード データの将来の作成がこれとどのように競合するかを理解できません。

もちろん、長期的な解決策は、開発文化の変化と手動の DB 変更の完全な禁止です。

于 2012-05-08T18:26:15.377 に答える
0

sqlplus を使用してスクリプトを実行している場合は、最初に次のステートメントを追加できます。

WHENEVER SQLERROR CONTINUE
于 2012-05-08T16:53:04.887 に答える
0

SQLERROR CONTINUE および DBMS_OUTPUT.PUT_LINE() が Flyway で機能しない場合は、SQLPLUS クライアント固有であるため、RAISE を使用できます。

EXCEPTION

WHEN OTHERS THEN

DBMS_OUTPUT.PUT_LINE(SQLERRM || CHR(10) ||DBMS_UTILITY.FORMAT_ERROR_BACKTRACE);

ROLLBACK;

Raise_Application_Error (-20000, SQLERRM || ' : ' ||DBMS_UTILITY.FORMAT_ERROR_BACKTRACE);

END;

Flyway は移行プロセスを停止し、問題をログに記録します。

移行を続行したい場合は、ユーザーがレイズしないで、別の印刷ソリューションを使用してください。flyway 4.0.3でテスト済み

于 2017-01-05T10:29:39.383 に答える