Hi again Jim,
2011/7/14 Jim Talbut <jtal...@spudsoft.co.uk>
> On 13/07/2011 21:14, Pinaki Poddar wrote:
>
>> 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.
>>
> I also went with using the OpenJPA stored version of the original object.
> There are a few niggles to getting that data that one has to work with, but
> I still think it's considerably less effort than building your own
> mechanism.
>
> 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.
>>
> I'd agree with that for a general purpose audit facility.
> In my case I don't even call it "audit" it's change tracking, and the
> change information is displayed alongside the entities in the most common
> cases.
>
> 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.
>>
> Again, true for a general purpose audit facility.
> If you want to be really secure the audit log should be sent directly to a
> printer :)
>
>
> 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);
>> }
>>
>
> I wonder if that bends the rules any more than my approach?
>
Exactly what I was thinking. Since you seem to be bending the rules in your
approach as well (creating new entities in the @PreUpdate), why not bend it
a little more? The benefit is that you can get the audit logging out of the
domain model (if you want to). Also, in my case, I have no use for the join
table between my entities so it feel nice to get rid of it...
Since neither of these approaches are supported by JPA but depends on the
implementation of OpenJPA, one might as well choose the most convenient one.
It'd be nice though if at least OpenJPA could officially support this kind
of mechanism since I think it's needed in real life anyway.
/Bengt
>
> Jim
>
