Jim, Why do you think that your approach is not supported by JPA? From other posts on this list I've seen that you are allowed to add/enrich your entity in the PreUpdate/PreCreate callbacks. That's all you are doing right. Then JPA persists your enriched entities.
What do you violate? /Bengt 2011/7/12 Jim Talbut <jtal...@spudsoft.co.uk> > 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 >
