9

アプリケーションが初めてマシン上で実行されるたびに、Hibernate がすべてのテーブル スキーマを作成するアプリケーションがあります。これはうまく機能します。

ただし、Hibernate にデータベースをバージョン管理下に保つ何らかのメカニズムがあるかどうか疑問に思っていました。つまり、Hibernate は、別のバージョンのアプリケーションを実行し、Hibernate が古いスキーマとは異なるデータベース スキーマを見つけたときに、あるスキーマを別のスキーマに移行する方法を知っているのでしょうか。バージョンは存在しますか? Hibernate が既存のスキーマを読み取ることができ、スキーマをマッピングの説明と比較できることを考えると、これは可能なはずだと思います。ただし、Liquibase / Flyway などで変更スクリプトを作成するときのように、Hibernate に古いデータを移行するように指示する方法がわかりません。

Hibernate とバージョン管理では、監査とフィールド バージョン管理で多くのヒットが表示されるため、正しいことをグーグルで調べていない可能性がありますが、Liquibase / Flyway の種類のバージョン管理に関してもっと考えています。両方を一緒に考えたことはありませんでしたが、Hibernate は更新スクリプトを作成せず、データベースを直接操作するため、両方を一緒に機能させる方法がわかりません。

独自のスクリプトを作成する代わりに、Hibernate にスキーマを作成させるのはこれが初めてです。これは、 Hibernate Enversを利用して、スクリプトの手動作成を非常に面倒なものにするために行います。多分私は明らかな何かを見逃しています。この件についてご意見をお寄せいただきありがとうございます。

更新: 今日、Flyway の開発者と話をすることができました。彼は、良い解決策を知らないと言っていました。もしかして何もない？

4

1 に答える 1

11

私たちの Java/Hibernate プロジェクトでも同じ問題があり、コードの複製作業は必要ありませんでした。Hibernate の「更新」機能はまったく信頼できません。LiquidBase の方が優れていますが、100% フール プルーフでもありません。最終的に、次のプロセスを管理するための簡単なスクリプトを開発しました。

  1. 「現在の」データベース スキーマは、DEV データベースに対して直接 Hibernate によって常に生成されます。
  2. 「以前の」データベース スキーマは、一連の LiquiBase 変更セットによって生成されます。
  3. 移行が必要になるたびに、LiquiBase の「差分」関数が「前の」データベースと「現在の」データベース (2 つの実際のデータベース、そうです、その方が確実です) の間で呼び出され、新しい LiquiBase 変更セットが生成されます。
  4. この変更セットは手動で確認する必要があります。すべての変更セットはソース コード管理に保持されます。
  5. PRODUCTION データベースには、すべての LiquiBase 変更セットを適用することによって生成されたスキーマがあります。

スクリプトのキー コマンドは次のようになります。

${LIQB_COMMAND} ${PREV_DB_OPTIONS} --changeLogFile=${LIQB_CHGLOG_FILE_NEW}  \
    diffChangeLog \
                --referenceUsername=${DEV_DB_USER} \
                --referencePassword=${DEV_DB_PWD} \
                --referenceDriver=com.mysql.jdbc.Driver \
                --referenceUrl=${DEV_DB_URL}

このように、移行プロセスは非常に信頼性が高く、スキーマ コードを 2 回記述する必要はありません。XML で生成された変更セットを手動で確認しますが、ほとんどの場合問題はなく、スキーマ変更操作を手動で記述するよりもはるかに簡単です。

于 2013-09-15T06:19:08.530 に答える