15

自己実装のバージョン管理ソリューションからHibernateEnversに切り替えることを考えていますが、まだよくわかりません。私はそれについてたくさん読みましたが、スキーマの変更と、古いスキーマに従ってデータを履歴化した後のEnversがそれらをどのように処理するかについて心配しています。

この点で、エンバーズでのあなたの経験は何ですか？Enversでスキーマの変更と既存のデータをどのように処理しますか？

アップデート1：

これは、テーブルから単純な列を削除することを追加するだけでなく、たとえば、単純なForein-Key-Relationshipを2つの1：n-relationshipsを持つ別のエンティティに変更する場合（属性付きの列を持つM2M。これは、データモデル。古いモデルに従ってすでに履歴データが存在する場合に、Enversを使用するときに、どのように対処しますか？手動でSQLスクリプトを記述し、それらを新しい表現に転送する方法はありますか？

4

3 に答える 3

4

私の経験では、Envers はすべてのフィールドをエンティティ テーブルからその監査テーブルにコピーするだけです。監査テーブルにコピーされたフィールドには、null 可能性や外部キーの制約などの制約がないため、実際のテーブルでそのような制約を追加または削除しても問題はありません。エンティティに追加するあらゆる種類の関係は、Envers の下に追加された新しい監査列および/またはテーブルにすぎず、歴史的なコンテキストでそれらを正しく解釈するのはあなた次第です。

あなたの例では、結合列ベースの関係から結合テーブルベースの関係に切り替えることを正しく理解していれば、古い結合列が結合テーブルと共存し、カットオーバーの時点で単純に、前者は後者を支持して移入されなくなります。この切り替えを行ったという事実を含め、履歴は完全に保存されます。すべての古いデータを監査テーブルの新しいモデルに適合させたい場合は、移行を行う必要があります。

于 2012-06-04T04:03:40.680 に答える
2

Envers は @Entities に依存して監査テーブルを作成するため、既存のスキーマを変更しても問題はないはずです。したがって、既存のテーブルに列を追加または削除しても、この変更が @Entity / @Audited JavaBean に反映されている限り、問題ありません。

于 2011-07-30T23:56:14.970 に答える
1

外部キーのリファクタリングは、Envers でうまくいくはずです。Envers は 1 対多の関係でも結合テーブルを作成するので、多対多の関係に変更するのは簡単なはずです。公式文書から 1 つの段落を抽出しました。

9.3. @OneToMany+@JoinColumn

これら 2 つの注釈を使用してコレクションがマップされると、Hibernate は結合テーブルを生成しません。ただし、関連するエンティティが変更されたリビジョンを読み取るときに、誤った結果が得られないように、Envers はこれを行う必要があります。

追加の結合テーブルに名前を付けることができるようにするために、JPA の @JoinTable と同様のセマンティクスを持つ @AuditJoinTable という特別な注釈があります。

1 つの特別なケースは、一方の側で @OneToMany+@JoinColumn を使用してマップされ、多側で @ManyToOne+@JoinColumn(insertable=false, updatetable=false) でマップされたリレーションです。このような関係は実際には双方向ですが、所有側はコレクションです (こちらも参照)。

このような Envers との関係を適切に監査するには、 @AuditMappedBy アノテーションを使用できます。(mappedBy 要素を使用して) reverse プロパティを指定できます。インデックス付きコレクションの場合、インデックス列も参照先エンティティにマップする必要があり (@Column(insertable=false, updatetable=false) を使用)、positionMappedBy を使用して指定する必要があります。この注釈は、Envers の動作方法にのみ影響します。注釈は実験的なものであり、将来変更される可能性があります。

于 2012-06-04T03:35:11.753 に答える