cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Automatically aligning ObjectContexts when establishing a relationship
Date Tue, 20 Dec 2016 06:07:04 GMT
(sending this back to user@)

Actually we detect context mismatch and throw inside the setter:

So my idea was to use 'localObject' instead. And I agree with the rest of your assessment.


> On Dec 20, 2016, at 2:55 AM, Aristedes Maniatis <> 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
>> Andrus
>>> On Dec 19, 2016, at 2:55 PM, Aristedes Maniatis <> 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
>>>> 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

View raw message