0

enversを使用してメーカーチェッカー機能のこれらのユースケースを解決する方法を教えてください。

1) 作成者は、エンティティ (部門など) を作成する要求を作成します。エンティティ テーブルにデータを挿入しないでください。監査表に記録する必要があります

2) チェッカーは承認のためにエンティティのリストを取得します -- データは監査テーブルからクエリする必要があります

3) チェッカーは保留中のリクエストを表示します -- 元のレコードを変更とともに表示します

4) チェッカーがリクエストを承認します -- データが監査テーブルからエンティティ テーブルに移動/上書きされます。

5) メーカーによるエンティティの変更要求 -- エンティティ テーブルは変更されません。変更は監査テーブルに記録されます。変更は、承認時にのみエンティティ テーブルを移動します。

このソリューションは、次の制約に対処することが期待されています

1) マスター/ディテール、つまり部門には従業員が含まれます

2) 一括承認、つまり、部門に 10,000 人の従業員がいる場合、承認プロセスは妥当なパフォーマンスを発揮するはずです。最後のユース ケースでは、データの検証 + 承認ルール + 監査テーブルからエンティティ テーブルへのデータの移動を実行する必要があります。

3) 上記のユースケースはすべてマスター/ディテールに適用されます。

envers の専門家から知りたいのですが、 envers を使用して上記のすべてのユースケースを実装することは可能ですか? Envers にはどのような変更が必要ですか?

よろしくお願いします -- Kiran.Kumar

4

1 に答える 1

1

envers の専門家から知りたいのですが、 envers を使用して上記のすべてのユースケースを実装することは可能ですか?

私は Envers に関する専門家ではありませんが、Envers で実行できるケースはほとんどありません。理由は非常に単純です。特定のユース ケースが多すぎて、一般的なソリューションを使用できないからです。

あなたの立場では、「承認日」と「承認者」を定義する「検証可能」(またはそのようなもの)と呼ばれるインターフェースを指定します。ビジネス メソッドは、まだ承認されていないエンティティを取得して処理する役割を担います。最初にエンティティを 1 つのテーブルに格納してから、エンティティを別のテーブルに移動することは現実的ではないことに注意してください。

于 2011-02-24T05:56:13.037 に答える