I agree that the current behavior is better. However, adding a localObjects(...) method that takes a var-args list would be helpful. deleteObjects is already like this.
On Mon, Dec 19, 2016 at 5:01 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
