Hi all. I’d just like to chime in to mention how ridiculously useful this feature has turned out to be. I’ve been using it since day one for audit logging, but I’ve since used it in many other places to react to changes in the object graph. Really, really nice.
Cheers, - hugi > On 9. okt. 2015, at 19:49, Andrus Adamchik <and...@objectstyle.org> wrote: > > Just committed an updated version that supports to-many relationships. > Altered the model of individual object changes to separately track changes to > attributes, to-one and to-many relationships: > > https://github.com/apache/cayenne/blob/master/cayenne-lifecycle/src/main/java/org/apache/cayenne/lifecycle/changemap/ObjectChange.java > > Eventually we should probably reuse this model for internal Cayenne change > tracking. It seems universal enough, will allow ObjectContext users to > inspect changes prior to commit (which is doable now, but not easy), and will > avoid multiple copies of "diffs". > > Andrus > > >> On Sep 29, 2015, at 5:46 AM, Andrus Adamchik <and...@objectstyle.org> wrote: >> >> I just sent a pull request with the first cut of the implementation. My plan >> is to try this new implementation with my audit system and if it works well, >> apply it to master (hopefully by then CAY-2028 will also be ready). The >> implementation I ended up with does not have JSON serialization. Just pure >> objects. Here is how it works: >> >> 1. Write a listener (currently requires an interface, but if needed we can >> easily switch to annotations) : >> >> public class L implements PostCommitListener { >> >> @Override >> public void onPostCommit(ObjectContext originatingContext, ChangeMap >> changes) { >> // do something with your changes >> } >> } >> >> 2. Configure Cayenne stack with "PostCommit" module: >> >> Module m = PostCommitModuleBuilder.builder().listener(L1.class); >> ServerRuntime r = ServerRuntimeBuilder >> .builder() >> .addConfig("cayenne-lifecycle.xml") >> .addModule(m) >> .build(); >> >> >> PostCommitModuleBuilder supports a few non-default options, such as >> excluding entities, entity properties, and hiding "confidential" property >> values, such as passwords using the existing @Auditable annotation. Or you >> can write a custom PostCommitEntityFactory to support your own annotations. >> >> TODO: there is not support for @AuditableChild yet. Need to think how to >> better handle this one. >> >> Comments are welcomed. >> >> Andrus >
