Hi John, We currently call PRE_PERSIST and PRE_UPDATE in a bad place - the context has already started the commit, analyzed the changes and passed them down to DataDomain. So there's a big difference with these 2 as compared to say POST_ADD and PRE_REMOVE. And I am not even sure what happens if you change objects in the same context with the former :) I suspect Cayenne will not be able to pick up your new changes.
So almost looks like we need a better events model. Perhaps taking PRE_PERSIST and PRE_UPDATE out of the DataDomain and into the ObjectContext, invoked before the context analyzes object deltas and sends them downstream. And then adding the code that you mentioned - catching updates that are the results of PRE_UPDATE invocation on some other object. Should be a fun algorithm to implement :) Totally doable of course, but we need to ensure there's no endless recursion, etc. Andrus > On Sep 15, 2015, at 2:16 PM, John Huss <johnth...@gmail.com> wrote: > > I've noticed that during the PRE_UPDATE lifecycle callback, if you update a > different object the PRE_UPDATE callback is not invoked for that object > before the commit occurs. It would be preferable to have the callback > still execute before the commit. > > For example, > > I am using PRE_UPDATE to conditionally update a modification time > attribute. In some cases I want to update other objects in PRE_UPDATE as > well in response to a change. If I do that I find that PRE_UPDATE is not > being called on these other objects and that their modification time > doesn't change (although all the changes as saved). > > Is it ok to change this behavior? I assume PRE_PERSIST behaves the same > way, but I haven't tried it. > > John
