I think the current behavior should be kept, or at least the default. I can see some value in being able to do this, though:
c1.setAutomaticContextBridging(true); Allow the developer to set it on a per-context basis when it simplifies their code and is more explicit and localized. mrg On Mon, Dec 19, 2016 at 6:00 AM, Andrus Adamchik <[email protected]> wrote: > We've had a concept of "persistence by reachability" for a long time. When > a relationship is established between 2 objects, if one of them is in an > ObjectContext and another one is not, we'd automatically register the > transient object using the context of the persistent objects. > > Now consider a different case... If a relationship is established between > 2 objects that are both registered, but in 2 different contexts, the > current behavior is to throw an exception. I am trying to decide whether it > is wise to resolve cross-context conflict quietly instead, replacing the > target object with a copy local to the source ObjectContext by calling > ObjectContext.localObject(..). This should remove a fair amount of > boilerplate if you are using multiple contexts throughout the app as I do. > > It doesn't come free though. The the code then becomes more obscure and > error-prone. E.g.: > > A a = ; // in c1 > B b = ; // in c2 > > a.setB(b); // equivalent to a.setB(c1.localObject(b)) > // i.e. we are attaching a different copy of B now. > > b.setProp("newValue"); // we may not realize that we are changing the > wrong copy... > c1.commitChanges(); // "b" changes are not committed. oops... > > I am leaning towards leaving things as they are, but maybe someone has > better ideas on how to keep it both convenient and robust at the same time > :) > > Thanks, > Andrus
