Just tried your suggestion Pinaki - it works fine and I can keep the audit
logging completely separate from my domain model. I even get rid of the join
table.
Now if this were clearly supported by OpenJPA (and by JPA in the future) I
think we have a clear winner...
/Bengt
2011/7/14 Bengt Rodehav <be...@rodehav.com>
> Pinaki,
>
> I agree with all your statements. I would like to keep the audit logging
> out of my business domain (separating of concerns). I just hadn't found a
> good way of doing this with JPA yet. Jim's approach gave me a way of being
> able to create new entities in @PreUpdate however with the drawbacks I
> mentioned (where one is that the domain model is affected).
>
> Your solution avoided the relationship but didn't give a way to store the
> audit log in a separate table. I fully agree that the persistence of the
> audit logging should be independent of the domain objects and could even be
> in log files.
>
> I have been thinking of the approach you suggest but I didn't think it was
> supported. I'm sure it's not supported by JPA since it seems you're not
> allowed to create new entities in a @PreUpdate. Is it supported by OpenJPA?
> Will it stay supported?
>
> Thanks for your advice - I appreciate it,
>
> /Bengt
>
> 2011/7/13 Pinaki Poddar <ppod...@apache.org>
>
>> Hi,
>>
>>
>> > On PreUpdate I save an audit log entry describing the current entity.
>> > However, I guess I should
>> > audit log the object in its previous state not its current state -
>> > otherwise I need to audit log in the PreCreate as well - right? I think
>> > I'll have to use your solution, Pinaki, to get the previous state of the
>> > object since
>> > that's what I have to log in the PreUpdate.
>> >
>>
>> Yes. Any audit facility needs to have a snapshot of the entity when it
>> entered a persistence context, so at @PreUpdate or at any other time
>> points,
>> it can figure out what has essentially been changed about that entity in a
>> transaction. Now either one can build their own mechanics to store the
>> original state of the entity or can use OpenJPA's own facility to access
>> the
>> original state. The blog article showed the later approach.
>>
>> Secondly, in my view, an audit facility should be orthogonal. The actual
>> domain entity need not know that it is being audited. Thereby, the domain
>> entity need not have an association or knowledge of an Audit object.
>>
>> Thirdly, the audit facility should allow the audit information be stored
>> in
>> a separate database, in the same database or may even be logged in a file.
>> That is to say that persistence of audit information should be decoupled
>> from persistence of the domain objects.
>>
>> If you intend to store audit information as a persistent entity in the
>> same
>> database as the domain entity, then the simple solution is something like
>> this in a domain class:
>>
>> @PreUpdate
>> public void audit() {
>> Audit audit = new Audit();
>> // now populate audit information
>> // .... some serious delta computation
>>
>> // Now get the entity manager that is managing this current
>> domain
>> object
>> OpenJPAEntityManager em =
>> OpenJPAPersistence.getEntityManager(this);
>>
>> // And persist the audit information in the same transaction
>> em.persist(audit);
>> }
>>
>>
>>
>>
>>
>> -----
>> Pinaki Poddar
>> Chair, Apache OpenJPA Project
>> --
>> View this message in context:
>> http://openjpa.208410.n2.nabble.com/Audit-log-with-OpenJPA-tp6557932p6580549.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>
>
