Yes, exactly. When your "editing" contexts are narrowly scoped, you have to transfer objects all the time.
And now I am also dealing with an issue of framework support (Tapestry specifically). A master object on an editor page lives in a page-scoped context. Master's to-one relationships are modified via a dropdown (<t:select value="mainObject.rel"/>). So setters are called by Tapestry, and related objects are deserialized with Tapestry ValueEncoder, ending up in a shared context. I have a working solution outside Cayenne (tracking my page-scoped context via a service, and making it accessible to the ValueEncoder). But hoped I could do it directly somehow. Andrus > On Dec 19, 2016, at 2:55 PM, Aristedes Maniatis <[email protected]> wrote: > > On 19/12/16 10:00pm, Andrus Adamchik wrote: >> 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... > > And this gets even messier if the related object is new and not yet persisted > at all. And if there are constraints. > > I'm trying to imagine what sort of app hits these types of issues. Is this > typically where there is one big read-only context and then a user might > modify some of those records, so they are copied into a local read-write > context for that user? > > > Ari > > > > -- > --------------------------> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
