Good idea.. Also a flavor that takes a collection arg. Andrus
> On Dec 20, 2016, at 6:06 AM, John Huss <[email protected]> wrote: > > 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
