Jim,
I was making generic statements about audit and was not meant to address
the specific approach you might have taken to suit your needs. I will take a
closer look at the approach you have come up with.
About 'delta computation', however, I find OpenJPA provides strong feature
via its SavePointManager and restore facility. The advantage is that leaves
the callback listeners stateless. Also, the managed entity knows which
fields have been modified/dirtied -- which is essential to any delta
computation.
Bengt,
Good to know you have made it working.
Now the question/concern about spec-compliance what is permissible in
@PreUpdate
a) JPA spec so far have discouraged entity modification in callbacks.
Specifically,
JPA 2.0 spec does not allow access to EntityManager and modification of
existing relations. These restrictions stem from the concern to maintain the
referential and transactional integrity of the unit of work. But as the
footnote in page 93 (Section 3.5) mentions, the idea is to make this area of
the spec more standardized in future.
As the spec moves forward, we expect that new entity creation in @Pre-
callbacks are likely to be supported. Changing existing relations may not.
You are welcome to contribute your views to the JSR-318 mailing group.
b) Access to entity manager is quite likely to be standardized in future
version of the spec. In expert group for version 2.1, we have seen several
requests on this aspect.
So the broad approach for audit/change tracking via callback listeners,
that we have been discussing in this thread, is aligned with the evolution
of JPA specification. You are not taking a non-kosher approach.
-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context:
http://openjpa.208410.n2.nabble.com/Audit-log-with-OpenJPA-tp6557932p6583813.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
