問題タブ [flyway]

MyBatis の移行では、各 SQL ファイルが 2 つのセクションに分割されます。

1. 1 つ前のバージョンに移行するための 1 つ
2. 1 つ前のバージョンに移行するための 1 つ

Flywayを使用してバージョンをロールバックするにはどうすればよいですか?

現在、データベース用の簡単な移行スクリプトをいくつか設定しようとしています。flywayをチェックしていましたが、これは必要なものに対して十分に単純なようです。私の問題は、Postgres ではバージョン 9 しかサポートされていないことです (私たちは 8.4 を使用しています)。どうにかしてこの制限を回避/修正することは可能ですか、それとも他のオプションを探し始める必要がありますか?

編集mvn flyway:status：次のようなものを実行すると、エラーメッセージが表示されることを忘れていました：

経由psqlで DB に接続でき、正しい jdbc ドライバーを使用しているため、ドキュメントの要件ページを見たとき、バージョンがflywayによって明示的にチェックされていると想定しました。

同じライフサイクルを持つ複数のスキーマで Flyway を使用して DB 移行を使用する場合、flyway:clean を使用するとすべてがクリーンになるようにするにはどうすればよいですか?

Mavenを使用してFlywayコマンドを単一のコマンドにチェーンするにはどうすればよいですか?

たとえば、 の後に を実行したいとしmvn initialize flyway:cleanますmvn initialize compile flyway:migrate。ただし、mvn initialize flyway:clean compile flyway:migrate失敗します。

ありがとう！

.earアーティファクト (JBoss 4.2)のデプロイ中に Flyway がデータベースを移行できれば幸いです。何か問題が発生した場合は中止する必要があります。

Flyway はmvn flyway:migrate機能しますが、継続的な統合と運用環境 (および新しいスナップショットをダウンロードする他の環境) では、アプリケーションに DB 移行がバンドルされていると便利です。

私はNomadと呼ぶFlywayのラッパーを作成しました。Flywayは、Mavenの外部で実行される絶え間ないロギングを除いて非常に満足しています。ここで問題を作成しました。Nomadの各ユーザーは、Flywayを無音にするために、log4jの独自の構成を作成する必要があります。これは、たとえば仕様テスト中に行われなかった場合に問題になります。ただし、構成を適切に行うことは困難であり、さらに、これを行う必要があると、ライブラリの抽象化が損なわれます。

私の質問はこれです：Nomadのユーザーがタスクに負担をかけないように、どうすればフライウェイを永久に沈黙させることができますか？私はこれがlog4j.xml 時々うまくいくことを発見しました：

これにより、Flywayは、過度におしゃべりではなく、役立つようになります。誤った方向性はまだ壊れていますが、頻繁ではありません。

私は2つのファイルを持っています.db構造とdbデータsqlファイルです。(変更ファイルを作成しているプロジェクトにはまだ参加していません)。

これらのファイルのいずれかがmavenを使用して変更された場合、毎回ビルドする前にこれらのファイルを実行する方法はありますか?

私が持っている唯一のアイデアは、ファイルを変更するたびにファイルの名前を変更して（バージョンを上げて）、フライアウェイが確実にそれを取得するようにすることです。

おそらくAPIまたは他の「トリック」を使用して、よりスマートな方法はありますか?

ありがとう

--MB

ホットフィックスに対処するための最良の戦略は何ですか? Flyway FAQ セクションからの質問。この質問では：

1. アプリケーション バージョン 7 (および DB バージョン 7) が本番環境にデプロイされています
2. アプリ バージョン 8 で作業を開始
3. DB バージョン 8 が開発され、受け入れテスト環境にデプロイされます
4. バグは本番環境で特定されています
5. DB バージョン 7.1 が開発されており、受け入れテストを受ける必要があります

flyway:migrate が受け入れテスト環境に対して呼び出されると、v8 が既に実行されていることがわかるため、v7.1 を実行する必要はありません。

v7.1 は v8 と互換性がない可能性があり、これを分析するのは Flyway の責任ではないため、これは理にかなっています。フェイルファストは完全に理解できます。

一方、v7.1 を受け入れテスト環境にデプロイする唯一の方法は、データベースをクリーンアップし、ターゲット = v7.1 で flyway:migrate を実行して、使用された可能性のあるデータを破棄することです。

このケースを処理する、または clean + migrate.target=v7.1 が唯一のオプションであることに気付いていない機能はありますか?

flyway でデータベースの変更を直接呼び出す代わりに、データベースの移行を SQL ファイルに出力することは可能ですか?

create table DDL を使用して v1 移行を正常に実行しました。同じものをv2ファイルにコピーして実行しました-予想される検証エラーメッセージが表示されました：

バージョン 1.0.002 への移行 com.googlecode.flyway.core.exception.FlywayException: 行 1 でステートメントを実行中にエラーが発生しました: create table people(id number(10) primary key, name varchar2(301)) が原因で発生しました java.sql.SQLSyntaxErrorException : ORA-00955: name は既存のオブジェクトによってすでに使用されています Mig​​rationException: バージョン 1.0.002 への移行に失敗しました! バックアップを復元し、データベースとコードをロールバックしてください

v2 ファイルを修正し、flyway migrate を再度実行しました。エラーメッセージを返す

現在のスキーマ バージョン: 1.0.002 MigrationException: バージョン 1.0.002 への移行に失敗しました! バックアップを復元し、データベースとコードをロールバックしてください

私はデータベースのバックアップを取る段階ではありません - 単純に修正された DDL を実行しようとしています。私は現在、フライウェイクリーン以外の解決策を見ていません。Flyway が FAILED バージョンを再度実行できないのはなぜですか (チェックサムが変更された場合)。または、フライウェイのロールバック コマンドが必要ではありませんか?

そのようにコードを変更できることはわかっていますが、このように動作するように選択した理由はありますか?