I am ok with this as long as it doesn't break the ability for a to-
many relationship collections to (un)set reverse relationships when
regular collection add/remove methods are called.
> 1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking
> Persistent
> instead of DO as an argument (actually I already did it locally)
-1. I don't want to expose this API to the world, and also want to
keep it pluggable (which is not possible with a static class).
Andrus
On Nov 24, 2009, at 12:42 PM, Andrey Razumovsky wrote:
> Okay, I've run into same situation when trying to allow PO
> subclasses in DC,
> but now I don't see context setting reverse arcs at user's change. The
> problem is in difference between CC and DC property change
> processing. Sorry
> about being so detailed around the code, but I don't see how i can
> explain
> it otherwise.
>
> So, what DC does when setting an arc:
> 1. Sets the value, which invokes context.propertyChanged()
> 2. GraphAction just registers property change, nothing else
> 3. Updates reverse arc
> 4. GraphAction just registers property change, nothing else
>
> What CC does when setting an arc:
> 1. Sets the value, which invokes context.propertyChanged()
> 2. GraphAction just registers property change and...
> 3. ...updates reverse arc
> 4. with those ugly threadlocals in CCGraghAction ensures there are no
> infinite cycles
>
> I am sure the first approach is much better. I suggest that we:
> 1. Moving DO.addToManyTarget, etc to DataObjectUtils, taking
> Persistent
> instead of DO as an argument (actually I already did it locally)
> 2. Make PersistentObjectHolder and other classes like that invoke
> context.propertChanged() should invoke those methods instead
>
> Ideally this will allow to:
> 1. Leave only OCGraphAction and get rid of DCGraphAction and
> CCGraphAction
> with its ugly threadLocal
> 2. Get rid of PropertyChangeProcessingStrategy
> 3. Maybe, make client and server persistent holders more similiar
>
> 2009/4/5 Andrus Adamchik <andru..bjectstyle.org>
>
>> I committed the fix per CAY-1204. I encourage everybody using nested
>> contexts in ROP to test it and report any problems.
>>
>> The essence of the fix was to set a thread-local state for whatever
>> complex
>> sequence of events is going on when a relationship is changed,
>> determining
>> how the context should handle graph changes. Per new non-public
>> PropertyChangeProcessingStrategy enum, it is either of IGNORE,
>> RECORD,
>> RECORD_AND_PROCESS_REVERSE_ARCS (default). This allows to handle 3
>> common
>> scenarios:
>>
>> "update from the DataChannel"
>> "update from the child context"
>> "update by the user"
>>
>> While this particular commit diverges client and server contexts
>> further
>> from each other, contrary to our stated goal of merging them
>> together, I
>> think the approach has a potential to become *the* way to do things
>> throughout the stack. Ideally this will eliminate the method pairs of
>> "doSomthing / doSomethingDirectly" from the API, which was a
>> cornerstone of
>> the graph management since Cayenne 1.0.
>>
>> Andrus
>>
>>
>>
>> On Apr 5, 2009, at 11:31 AM, Andrus Adamchik wrote:
>>
>> Cool. I got a further along in my investigation. I will put the
>> details in
>>> a Jira and work on fixing it.
>>>
>>> Andrus
>>>
>>>
>>> On Apr 4, 2009, at 8:31 AM, Andrey Razumovsky wrote:
>>>
>>> Hi Andrus,
>>>>
>>>> I'm afraid I don't remember if it was done intentionally. I only
>>>> know
>>>> that
>>>> the code is different from normal contexts' diff processing
>>>> (that's why I
>>>> feel a large refactoring is needed). Feel free to change the
>>>> code, of
>>>> course. Alternatively, if you open a JIRA and post you JUnit
>>>> there, I'll
>>>> have a look.
>>>>
>>>> Andrey
>>>>
>>>> 2009/4/3 Andrus Adamchik <andru..bjectstyle.org>
>>>>
>>>> I am in the middle of debugging a problem with nested ROP contexts
>>>>> losing
>>>>> arc changes when committing to a parent context. Since I was not
>>>>> involved in
>>>>> the ROP nested context work, I figured I'd post my thoughts here
>>>>> before
>>>>> I
>>>>> start changing the code.
>>>>>
>>>>> I noticed that per CAY-1119, there is a special subclass of
>>>>> ChildDiffLoader
>>>>> called CayenneContextChildDiffLoader that calls
>>>>> 'propertyChanged' on the
>>>>> parent context after syncing a simple property change. It seems
>>>>> like we
>>>>> need
>>>>> to do the same for relationships as well, to record arc changes
>>>>> in the
>>>>> parent diff list.
>>>>>
>>>>> Andrey, do you have any comments on that? I wonder if it was
>>>>> omitted
>>>>> intentionally. I will open a Jira (I think we don't have one for
>>>>> this),
>>>>> and
>>>>> add some tests with various relationships, but before I dig any
>>>>> deeper
>>>>> figured I'll need a sanity check.
>>>>>
>>>>> Thanks,
>>>>> Andrus
>>>>>
>>>>>
>>>
>>>
>>
>
>
> --
> Andrey
This archive was generated by hypermail 2.0.0 : Tue Nov 24 2009 - 06:11:02 EST