> you actually store it in the object itself. That's right. This allows in-memory rollback.
Given that the entire 'clean' or 'original' state is available in the technique I described, the application can make several decisions on a) what should be logged in an audit trail -- the entire object in a separate database/schema, a serialized blob or a JSON stream or whatever. b) because the technique is based on OpenJPA internal, if an application decides to take the 'blue pill', then it can simply ask the managed object which fields have been 'dirtied' if it requires to compute delta efficiently. Another related but separate point: I have noticed lot of requests/annoyance from the users on the limitation of callback listener methods having no access to the persistence context. Again, in OpenJPA runtime, the managed entity does know its persistence context. If the application is ready for a OpenJPA-specific cast, then the handle to the persistence context is right there in the entity. ----- Pinaki -- View this message in context: http://openjpa.208410.n2.nabble.com/Audit-log-with-OpenJPA-tp6557932p6560548.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
