エンティティのリストが 2 つあります。1 つは DB 内の行の現在の状態で、もう 1 つはリストに加えられた変更です。削除、追加、およびエンティティに加えられた変更を監査するにはどうすればよいですか? 私の監査テーブルはすべてのエンティティで使用されています。
エンティティ リスナーと Callback メソッドは完全に適合しているように見えますが、次の文に気付くまでは: A callback method must not invoke EntityManager or Query Methods! この制限により、監査を収集することはできますが、データベースに永続化することはできません:(
私の解決策は、監査を発見するための複雑なアルゴリズムでした。
If the entity is in the change list and has no key, it's an add
If the entity is in the db but not the changes list, it's a delete
If the entity is in both list, recursively compare their fields to find differences to audit (if any)
これらを収集し、変更リストをマージするのと同じトランザクションで DB に挿入します。しかし、私はこれを手で書いているという事実が嫌いです。JPAは私のためにこのロジックを実行できるはずです。
私たちが思いついた解決策の 1 つは、監査を JMS キューに送信するエンティティ リスナーを使用することです。その後、キューは監査をデータベースに挿入します。しかし、JMS キューを設定するのが面倒だと思うので、この解決策は好きではありません。とはいえ、これが現時点での最善の解決策です。
私はeclipselinkを使用しています（理想的には、それは関係ありません）、役立つように見えるこれら2つのことを見つけましたが、JMSキューはそれらよりも優れたソリューションです：
- http://wiki.eclipse.org/EclipseLink/FAQ/JPA#How_to_access_what_changed_in_an_object_or_transaction.3Fこれは本当に使いにくそうです。フィールドを文字列で検索します。したがって、エンティティをリファクタリングしてこれを更新するのを忘れると、実行時エラーがスローされます。
- http://wiki.eclipse.org/EclipseLink/Examples/JPA/Historyこれは、現在の監査方法と一致しません。特別な
entity_historyテーブルが必要です。