How to identify fields that are made dirty during an InstanceCallback from within a listener?


ebenzacar@...
 

Hi Andy,

I'm running into a bit of a catch-22 solution here and would love some ideas if you have something.

I'm trying to identify all dirty fields of an object during a StoreLifecycleListener.  I have both the preStore() and postStore() methods implemented.
The catch-22 situation I'm running into is that only the preStore() has the dirty flags identified.  Once DN persists the data, it clears all the dirty flags and then calls the postStore() listeners.  So by the time it gets to the postStore() listener, all fields are "clean".


However, the preStore() LifecycleListener is fired _before_ the StoreCallback.jdoPreStore().  Which means that if a field is changed/modified in the jdoPreStore() I won't have access the updated data during the StoreLifecycleListener.preStore() event.

If I wait until the postStore() event to retrieve the value (since it is changed AFTER preStore()), then I have no way of identifying which field(s) were changed since the dirty flags are cleared by that point.

I'm a bit in a pickle; I want to try to identify exactly which field(s) and their value(s) were updated/sent to the DB, but cannot find the right approach.

Any ideas/thoughts?

Thanks,

Eric



Andy
 
Edited

The JDO spec (12.15) explicitly insists that InstanceLifecycleListener methods are called BEFORE InstanceCallbacks, so we can't just change the code to calls to the opposite order, hence using LifecycleListeners for this will always miss anything the user does subsequently (in jdoPreStore).

You could look at adding an extra (DN-specific) listener giving you the explicit info you require, for classes that you want to do auditing on. e.g AuditPersistListener, and then update JDOCallbackHandler to call all AuditPersistListener when all other listeners/callbacks have been called, i.e https://github.com/datanucleus/datanucleus-api-jdo/blob/master/src/main/java/org/datanucleus/api/jdo/JDOCallbackHandler.java#L159

Means a vendor extension so dependent on DN code, but then your solution will be either way.