> (sending this back to user@) Sorry, was supposed to be dev@ :)
> On Dec 20, 2016, at 9:07 AM, Andrus Adamchik <[email protected]> wrote: > > (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 <[email protected]> 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 <[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 >>> >> >> >> -- >> --------------------------> >> Aristedes Maniatis >> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
