(sending this back to user@) Actually we detect context mismatch and throw inside the setter:
https://github.com/apache/cayenne/blob/master/cayenne-server/src/main/java/org/apache/cayenne/CayenneDataObject.java#L389 So my idea was to use 'localObject' instead. And I agree with the rest of your assessment. Andrus > On Dec 20, 2016, at 2:55 AM, Aristedes Maniatis <a...@maniatis.org> wrote: > > If a context had some sort of explicit read-only flag, then this new > behaviour starts to make sense. That is: > > - objectA in read-only context > - edit objectB in new read-write context and join to objectA > > From what I remember, Cayenne doesn't throw an exception when you create the > join, only when you try to commit. What if we throw an exception at time of > join, which you could then catch and fix by copying objectA? Or if you are in > setAutomaticContextBridging(true) mode, then Cayenne catches the exception > and fixes it itself. > > Is that the idea you had in mind? > > > I think though, if we don't have an explicit 'read-only' mode for contexts, > then the level of foot shooting this would enable might be quite spectacular. > > > Ari > > > On 19/12/16 11:06pm, Andrus Adamchik wrote: >> 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 <a...@maniatis.org> 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 >> > > > -- > --------------------------> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
