Yeah, and later we can build something around "cayenne-commitlog" APIs. It still have pretty scary data structures (see ChangeMap and ObjectChange classes), but at least everything is well-organized by object and change type.
Andrus > On Oct 11, 2019, at 10:37 AM, John Huss <johnth...@gmail.com> wrote: > > Providing a "minimal viable product" type of implementation of this as a > starting point for users to customize or copy would probably be helpful. > > On Fri, Oct 11, 2019 at 9:35 AM Andrus Adamchik <and...@objectstyle.org> > wrote: > >> So you'd need to consume GraphDiff, you need to implement a custom >> GraphChangeHandler, and then do "diff.apply(myChangeHandler)" to aggregate >> / filter the changes you care about. All the references to "nodeId" in >> GraphChangeHandler can be cast to ObjectId, so you can tie it back to the >> actual objects. So while it is not user-friendly, I think you can turn it >> to useful info in a fairly straightforward manner. >> >> Andrus >> >> >>> On Oct 11, 2019, at 10:24 AM, John Huss <johnth...@gmail.com> wrote: >>> >>> I haven't worked with the GraphDiff API much, but it's not super easy to >>> turn a GraphDiff into something immediately useful. >>> >>> When I've needed things like this I've usually constructed a >>> List<Map<String, Object>> with a row for each changed object and a map >> with >>> attribute/relationship key to the new value. Looking at >>> NodePropertyChangeOperation - it has the key and the old and new value, >> but >>> the API doesn't have any way of extracting that information that I see. >>> >>> Most likely I just don't understand how to use this correctly, but I'm >>> guessing I wouldn't be the only one. >>> >>> On Fri, Oct 11, 2019 at 5:36 AM Andrus Adamchik <and...@objectstyle.org> >>> wrote: >>> >>>> Was just answering Cayenne change tracking question on StackOverlow [1], >>>> and realized that the only user-friendly API that allows to check for >>>> individual changes is "cayenne-commitlog" that only works during commit. >>>> All the pre-commit APIs are internal and require lots of hoop jumping. I >>>> think we can address that on the cheap in 4.2 by defining a method like >>>> this in GraphManager.java: >>>> >>>> GraphDiff getChanges(); >>>> >>>> We already have such method implemented in ObjectStore, so there's >> really >>>> no effort and an immediate benefit. Or take it a step further and >>>> additionally implement filtering changes per object: >>>> >>>> GraphDiff getChanges(Persistent) >>>> >>>> Thoughts? >>>> >>>> Andrus >>>> >>>> [1] >>>> >> https://stackoverflow.com/questions/58318730/what-is-the-current-best-method-of-getting-the-changes-to-an-object-hierarchy-in >> >>
