Thanks for responding. I hadn't seen DataChannelFilter as I was still on 3.0.
My use case is forcing a failure during a commit during testing. Lifecycle callbacks won't work because I need to do something during a DataContext commit rather than for individual entity changes as the entities involved are not always easily known. DataChannelFilter looks like it will give me what I need. It looks like I'll need to upgrade to 3.1 in order to use DataChannelFilter. I need to do a little more debugging and testing under 3.0 before I upgrade to 3.1, so I will stick with my local modification to generate a DATACONTEXT_WILL_COMMIT event using EventManager for now, then upgrade to DataChannelFilter. On Sun, Sep 15, 2013 at 4:45 AM, Andrus Adamchik <[email protected]> wrote: > Hi Mike, > > We've been gradually moving from "event" to "callback" and model for object > lifecycle tracking and to "interceptor" model for transaction state tracking. > In practical terms this means that events dispatched via EventManager should > be considered internal to the framework (there are probably exceptions to > this rule, but that's the general direction). User application should instead > be using callbacks on objects / listeners to receive per-object events and > DataChannelFilter [1] to intercept transactions. The 2 approaches are > synergetic and are often combined together [2]. > > Will that be sufficient for your use cases? > > Andrus > > > [1] > http://cayenne.apache.org/docs/3.1/api/org/apache/cayenne/DataChannelFilter.html > [2] > http://cayenne.apache.org/docs/3.1/cayenne-guide/lifecycle-events.html#comining-listeners-with-datachannelfilters > > On Sep 13, 2013, at 9:32 PM, Mike Kienenberger <[email protected]> wrote: >> So I'm finally making the attempt to upgrade my ancient Cayenne >> project from 1.1 to 3.x. >> >> The one kind of compile error I still haven't resolved is registering >> for a data context commit. >> >> I know I can register individual PrePersist, PreRemove, and PreUpdate >> callbacks for individual entity types, but I don't see how I be >> notified of with a single DataContext.WILL_COMMIT event once before >> each context.commit(). >> >> >> I see three problems with trying to use the individual callbacks: >> >> - Huge performance hit of being notified for each and every entity committed >> >> - Another performance hit of setting up lifecycle notification by >> iterating through the runtime metadata to register every existing >> entity type for each of the three pre-commit listeners >> >> and >> >> - If nothing gets changed by the commit, then I would still get no >> notification. >> >
