On 12/07/2011 08:49, Bengt Rodehav wrote:
Your other design decision is also interesting. By having a relationship to
the audit log entries JPA will persist the audit log entry for you - very
convenient indeed. A little similar to the way Pinaki described previously.
However you store the audit log in a separate table while Pinaki stores the
audit log together with the entity (in a separate column) that is being
persisted. I kind of like your approach better. I think an audit log can be
viewed from two different angles: the entity view and the user view. You
need to be able to see what changes have been made to an entity and possibly
even implment undo (like Pinaki). However, you also need to be able to track
all changes done by a specific user during a specific time period. The
latter is much easier with a centralized place for all audit log entries.
Can't really see how that can easily be done with Pinaki's approach.
With the specifics of my implementation undo would be very awkward to
implement, but that's because I'm trying to produce a textual change
tracking log rather than an undo per-se.
I could modify my layout to support undo, but it would still be more
complex than a model that put the undo records in the original table.
The only thing I might miss from your solution then is the ability to
configure whether audit logging is enabled for an entity or not. Our
customers have different requirements here. But then again, this should be
possible in your approach as well. In the @PreUpdate method I could check
(somehow) if audit logging is enabled for this entity. If yes, then create
the audit log entry and add it to the collection. If not, then don't create
the audit log entry and nothing will be logged - right?
That's right.
For my purposes I don't want to exclude any entities of a given type -
so three different (unrelated) entity classes perform auditing but there
is no filtering of entities of an audited type.
Have you had the need to configure OpenJPA in some specific way for
performance reasons? I guess you really want to avoid OpenJPA fetching all
your audit log entries every time an entity is fetched...
All I've done is make the audit entries lazy-fetch and I believe that
works (though honestly I haven't actually tested it).
Also, I need to know whether this is a supported JPA/OpenJPA way of doing
things. My guess is yes since you don't actually use the entity manager
yourself.
It's not, that's the big downside.
The only way you're going to get an official approach is with a JDBC
call in the same transaction (which I ditched because of the
difficulties of getting hold of the transactional context and other
things from within the listener).
If I find that the approach fails in a future version of OpenJPA I'll
switch to JDBC, by having the entities in a separate table this is quite
a clean swap and the only difficulty is getting the necessary context
available at the right place.
Jim
