You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2009/04/02 22:29:14 UTC
Nested ROP contexts and relationships
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
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.org>.
> my war against two branches of classes continues :)
Great job :-)
> -added little test (LightServerTest) for testing ROP-like server
> classes.
> very simple, still need to figure out how to create test stacks for
> server &
> client at once
As a side note, I was thinking of an overhaul of the test framework
for some time. Tests under cayenne-jdk1.5-unpublished are rather hard
to manage. E.g. group by DB type (some tests are not supported on some
DB's), create data assemblies, etc. There's also lots of obsolete
stuff (like Spring-based SQL queries).
Olga did research on the background of JUnit4 and TestNG as the
possible alternatives. This is a topic for separate thread, I was just
holding it off intentionally, as we had a bunch of other active
discussions and it's been a bit overwhelming to follow all of them.
> -added util.Cayenne class with some internal and external methods
Excellent! May I nitpick a bit ? :-)
Can we split non-public methods into a non-public class under the util
package (maybe even the existing org.apache.cayenne.util.Util), and
move Cayenne to org.apache.cayenne package?
Also since DataObjectUtils deprecation is a pretty serious frontend
change, can we open a Jira for tracking purposes (and close it right
after putting it in RELEASE-NOTES).
Andrus
On Nov 24, 2009, at 10:36 PM, Andrey Razumovsky wrote:
> Just committed changes in ROP event processing. In a nutshell,
> changes are:
> -removed all ThreadLocals and PropertyChangeProcessingStrategy
> -removed CCGraphAction & DCGraphAction to the glory of OCGraphAction
> -added to methods to ToManyProperty
> -added util.Cayenne class with some internal and external methods
> -added new "Light Server Superclass" template. It allows to generate
> ROP-like server classes (in fact, it allows same classes for server &
> client). Classes like that can be generated through "Advanced" menu.
> Currently it is adviced to set superclass
> "org.apache.cayenne.PersistentObject" (nothing else tested)
> -added little test (LightServerTest) for testing ROP-like server
> classes.
> very simple, still need to figure out how to create test stacks for
> server &
> client at once
>
> my war against two branches of classes continues :)
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
Just committed changes in ROP event processing. In a nutshell, changes are:
-removed all ThreadLocals and PropertyChangeProcessingStrategy
-removed CCGraphAction & DCGraphAction to the glory of OCGraphAction
-added to methods to ToManyProperty
-added util.Cayenne class with some internal and external methods
-added new "Light Server Superclass" template. It allows to generate
ROP-like server classes (in fact, it allows same classes for server &
client). Classes like that can be generated through "Advanced" menu.
Currently it is adviced to set superclass
"org.apache.cayenne.PersistentObject" (nothing else tested)
-added little test (LightServerTest) for testing ROP-like server classes.
very simple, still need to figure out how to create test stacks for server &
client at once
my war against two branches of classes continues :)
Re: DO/PO design
Posted by Andrus Adamchik <an...@objectstyle.org>.
Exactly, I also thought of generating an internal enum of attribute
keys. From there we can either use an EnumMap wrapper of object[] or
just the array.
Andrus
On Nov 30, 2009, at 12:23 PM, Tore Halset wrote:
> Hello.
>
> Would it be possible to have attributes within an entity as enum and
> then use EnumMap? It uses an array for storage, so it does not need
> the buly Map.Entry objects used in a normal HashMap.
>
> - Tore.
>
> On Nov 30, 2009, at 11:09 , Andrus Adamchik wrote:
>
>> Another possible "lightweight" design that would allow to reconcile
>> DO's and PO's is to use Object[] instead of either HashMap or ivars
>> to store values, with indexes in array corresponding to
>> ObjAttribute names sorted in alphabetic order. Will probably have
>> its own quirks I guess (e.g. how do we define the array size for a
>> generic object that can be mapped to different entities), however
>> it has some serious benefits:
>>
>> * memory use very close to ivars
>> * access speed very close to ivars
>> * can be used with Faults
>> * can be used with generic objects
>>
>> Andrus
>>
>>
>> On Nov 24, 2009, at 9:47 PM, Andrus Adamchik wrote:
>>
>>> True, but they are still user facing collections (or more
>>> generally valueholders, as this also works for to-one), that get
>>> inflated internally as needed. DO faults are singletons of this
>>> type:
>>>
>>> http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html
>>>
>>> So PO lazy relationship resolving goes like this:
>>>
>>> 1. on select, init lazy property with a "hollow" ValueHolder
>>> 2. on ValueHolder value access, inflate ValueHolder with the DB data
>>>
>>> For DO it has an extra step:
>>>
>>> 1. on select, init lazy property with a singleton Fault of a type
>>> corresponding to the relationship semantics
>>> 2. on property access, *replace* Fault with either a hollow
>>> collection or a target DO (which can be hollow or resolved from
>>> cache)
>>> 3. on collection or hollow DO value access, inflate them.
>>>
>>> The difference may be subtle, but still essential. First, in DO
>>> case there's no to-one ValueHolder. Target object is attached
>>> directly. Also the user never sees the Fault object itself, so we
>>> can replace it with another object when needed. Among other things
>>> this allows a major memory optimization, as Fault instances are
>>> singletons shared by all DOs.
>>>
>>> So all in all, DO design seems more sound (and quite possibly that
>>> whatever memory we save on using ivars in PO, is getting lost to
>>> extra and more eager ValueHolders).
>>>
>>> Andrus
>>>
>>>
>>> On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote:
>>>
>>>> Actually, I don't understand :) PO arc properties are all faults
>>>> (classes
>>>> PersistentObject*)
>>>>
>>>> 2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>>>>
>>>>>
>>>>> On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:
>>>>>
>>>>>
>>>>>>>
>>>>>>> So ... another attempt at abstract analysis (or an attempt at
>>>>>>> unwinding
>>>>>>> my
>>>>>>> memory...) IIRC the main difference between DO and PO is fault
>>>>>>> handling -
>>>>>>> we
>>>>>>> can store a Fault instance in a map, but not in a typed ivar.
>>>>>>> So PO's
>>>>>>> have
>>>>>>> no concepts of faults at all, and the lifecycle is different.
>>>>>>> DO approach
>>>>>>> is
>>>>>>> more lazy (it won't try to create even a placeholder
>>>>>>> collection until the
>>>>>>> property is accessed), and I prefer it to PO's. Wonder if when
>>>>>>> we
>>>>>>> reconcile
>>>>>>> that somehow, the rest will fall into place on its own??
>>>>>>>
>>>>>>> (E.g. for PO's, we generate extra boolean "fault" properties
>>>>>>> for each
>>>>>>> relationship, that are checked on every property access?)
>>>>>>>
>>>>>>>
>>>>>> Nice idea, need to think about it. But anyways, this is
>>>>>> separate task
>>>>>>
>>>>>
>>>>> May or may not be a separate task. But definitely bigger in scope.
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Andrey
>>>
>>>
>>
>>
>
>
Re: DO/PO design
Posted by Tore Halset <ha...@pvv.ntnu.no>.
Hello.
Would it be possible to have attributes within an entity as enum and
then use EnumMap? It uses an array for storage, so it does not need
the buly Map.Entry objects used in a normal HashMap.
- Tore.
On Nov 30, 2009, at 11:09 , Andrus Adamchik wrote:
> Another possible "lightweight" design that would allow to reconcile
> DO's and PO's is to use Object[] instead of either HashMap or ivars
> to store values, with indexes in array corresponding to ObjAttribute
> names sorted in alphabetic order. Will probably have its own quirks
> I guess (e.g. how do we define the array size for a generic object
> that can be mapped to different entities), however it has some
> serious benefits:
>
> * memory use very close to ivars
> * access speed very close to ivars
> * can be used with Faults
> * can be used with generic objects
>
> Andrus
>
>
> On Nov 24, 2009, at 9:47 PM, Andrus Adamchik wrote:
>
>> True, but they are still user facing collections (or more generally
>> valueholders, as this also works for to-one), that get inflated
>> internally as needed. DO faults are singletons of this type:
>>
>> http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html
>>
>> So PO lazy relationship resolving goes like this:
>>
>> 1. on select, init lazy property with a "hollow" ValueHolder
>> 2. on ValueHolder value access, inflate ValueHolder with the DB data
>>
>> For DO it has an extra step:
>>
>> 1. on select, init lazy property with a singleton Fault of a type
>> corresponding to the relationship semantics
>> 2. on property access, *replace* Fault with either a hollow
>> collection or a target DO (which can be hollow or resolved from
>> cache)
>> 3. on collection or hollow DO value access, inflate them.
>>
>> The difference may be subtle, but still essential. First, in DO
>> case there's no to-one ValueHolder. Target object is attached
>> directly. Also the user never sees the Fault object itself, so we
>> can replace it with another object when needed. Among other things
>> this allows a major memory optimization, as Fault instances are
>> singletons shared by all DOs.
>>
>> So all in all, DO design seems more sound (and quite possibly that
>> whatever memory we save on using ivars in PO, is getting lost to
>> extra and more eager ValueHolders).
>>
>> Andrus
>>
>>
>> On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote:
>>
>>> Actually, I don't understand :) PO arc properties are all faults
>>> (classes
>>> PersistentObject*)
>>>
>>> 2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>>>
>>>>
>>>> On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:
>>>>
>>>>
>>>>>>
>>>>>> So ... another attempt at abstract analysis (or an attempt at
>>>>>> unwinding
>>>>>> my
>>>>>> memory...) IIRC the main difference between DO and PO is fault
>>>>>> handling -
>>>>>> we
>>>>>> can store a Fault instance in a map, but not in a typed ivar.
>>>>>> So PO's
>>>>>> have
>>>>>> no concepts of faults at all, and the lifecycle is different.
>>>>>> DO approach
>>>>>> is
>>>>>> more lazy (it won't try to create even a placeholder collection
>>>>>> until the
>>>>>> property is accessed), and I prefer it to PO's. Wonder if when we
>>>>>> reconcile
>>>>>> that somehow, the rest will fall into place on its own??
>>>>>>
>>>>>> (E.g. for PO's, we generate extra boolean "fault" properties
>>>>>> for each
>>>>>> relationship, that are checked on every property access?)
>>>>>>
>>>>>>
>>>>> Nice idea, need to think about it. But anyways, this is separate
>>>>> task
>>>>>
>>>>
>>>> May or may not be a separate task. But definitely bigger in scope.
>>>>
>>>> Andrus
>>>>
>>>>
>>>
>>>
>>> --
>>> Andrey
>>
>>
>
>
DO/PO design
Posted by Andrus Adamchik <an...@objectstyle.org>.
Another possible "lightweight" design that would allow to reconcile
DO's and PO's is to use Object[] instead of either HashMap or ivars to
store values, with indexes in array corresponding to ObjAttribute
names sorted in alphabetic order. Will probably have its own quirks I
guess (e.g. how do we define the array size for a generic object that
can be mapped to different entities), however it has some serious
benefits:
* memory use very close to ivars
* access speed very close to ivars
* can be used with Faults
* can be used with generic objects
Andrus
On Nov 24, 2009, at 9:47 PM, Andrus Adamchik wrote:
> True, but they are still user facing collections (or more generally
> valueholders, as this also works for to-one), that get inflated
> internally as needed. DO faults are singletons of this type:
>
> http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html
>
> So PO lazy relationship resolving goes like this:
>
> 1. on select, init lazy property with a "hollow" ValueHolder
> 2. on ValueHolder value access, inflate ValueHolder with the DB data
>
> For DO it has an extra step:
>
> 1. on select, init lazy property with a singleton Fault of a type
> corresponding to the relationship semantics
> 2. on property access, *replace* Fault with either a hollow
> collection or a target DO (which can be hollow or resolved from cache)
> 3. on collection or hollow DO value access, inflate them.
>
> The difference may be subtle, but still essential. First, in DO case
> there's no to-one ValueHolder. Target object is attached directly.
> Also the user never sees the Fault object itself, so we can replace
> it with another object when needed. Among other things this allows a
> major memory optimization, as Fault instances are singletons shared
> by all DOs.
>
> So all in all, DO design seems more sound (and quite possibly that
> whatever memory we save on using ivars in PO, is getting lost to
> extra and more eager ValueHolders).
>
> Andrus
>
>
> On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote:
>
>> Actually, I don't understand :) PO arc properties are all faults
>> (classes
>> PersistentObject*)
>>
>> 2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>>
>>>
>>> On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:
>>>
>>>
>>>>>
>>>>> So ... another attempt at abstract analysis (or an attempt at
>>>>> unwinding
>>>>> my
>>>>> memory...) IIRC the main difference between DO and PO is fault
>>>>> handling -
>>>>> we
>>>>> can store a Fault instance in a map, but not in a typed ivar. So
>>>>> PO's
>>>>> have
>>>>> no concepts of faults at all, and the lifecycle is different. DO
>>>>> approach
>>>>> is
>>>>> more lazy (it won't try to create even a placeholder collection
>>>>> until the
>>>>> property is accessed), and I prefer it to PO's. Wonder if when we
>>>>> reconcile
>>>>> that somehow, the rest will fall into place on its own??
>>>>>
>>>>> (E.g. for PO's, we generate extra boolean "fault" properties for
>>>>> each
>>>>> relationship, that are checked on every property access?)
>>>>>
>>>>>
>>>> Nice idea, need to think about it. But anyways, this is separate
>>>> task
>>>>
>>>
>>> May or may not be a separate task. But definitely bigger in scope.
>>>
>>> Andrus
>>>
>>>
>>
>>
>> --
>> Andrey
>
>
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.org>.
True, but they are still user facing collections (or more generally
valueholders, as this also works for to-one), that get inflated
internally as needed. DO faults are singletons of this type:
http://cayenne.apache.org/doc/api/org/apache/cayenne/Fault.html
So PO lazy relationship resolving goes like this:
1. on select, init lazy property with a "hollow" ValueHolder
2. on ValueHolder value access, inflate ValueHolder with the DB data
For DO it has an extra step:
1. on select, init lazy property with a singleton Fault of a type
corresponding to the relationship semantics
2. on property access, *replace* Fault with either a hollow
collection or a target DO (which can be hollow or resolved from cache)
3. on collection or hollow DO value access, inflate them.
The difference may be subtle, but still essential. First, in DO case
there's no to-one ValueHolder. Target object is attached directly.
Also the user never sees the Fault object itself, so we can replace it
with another object when needed. Among other things this allows a
major memory optimization, as Fault instances are singletons shared by
all DOs.
So all in all, DO design seems more sound (and quite possibly that
whatever memory we save on using ivars in PO, is getting lost to extra
and more eager ValueHolders).
Andrus
On Nov 24, 2009, at 9:28 PM, Andrey Razumovsky wrote:
> Actually, I don't understand :) PO arc properties are all faults
> (classes
> PersistentObject*)
>
> 2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>
>>
>> On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:
>>
>>
>>>>
>>>> So ... another attempt at abstract analysis (or an attempt at
>>>> unwinding
>>>> my
>>>> memory...) IIRC the main difference between DO and PO is fault
>>>> handling -
>>>> we
>>>> can store a Fault instance in a map, but not in a typed ivar. So
>>>> PO's
>>>> have
>>>> no concepts of faults at all, and the lifecycle is different. DO
>>>> approach
>>>> is
>>>> more lazy (it won't try to create even a placeholder collection
>>>> until the
>>>> property is accessed), and I prefer it to PO's. Wonder if when we
>>>> reconcile
>>>> that somehow, the rest will fall into place on its own??
>>>>
>>>> (E.g. for PO's, we generate extra boolean "fault" properties for
>>>> each
>>>> relationship, that are checked on every property access?)
>>>>
>>>>
>>> Nice idea, need to think about it. But anyways, this is separate
>>> task
>>>
>>
>> May or may not be a separate task. But definitely bigger in scope.
>>
>> Andrus
>>
>>
>
>
> --
> Andrey
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
Actually, I don't understand :) PO arc properties are all faults (classes
PersistentObject*)
2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>
> On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:
>
>
>>>
>>> So ... another attempt at abstract analysis (or an attempt at unwinding
>>> my
>>> memory...) IIRC the main difference between DO and PO is fault handling -
>>> we
>>> can store a Fault instance in a map, but not in a typed ivar. So PO's
>>> have
>>> no concepts of faults at all, and the lifecycle is different. DO approach
>>> is
>>> more lazy (it won't try to create even a placeholder collection until the
>>> property is accessed), and I prefer it to PO's. Wonder if when we
>>> reconcile
>>> that somehow, the rest will fall into place on its own??
>>>
>>> (E.g. for PO's, we generate extra boolean "fault" properties for each
>>> relationship, that are checked on every property access?)
>>>
>>>
>> Nice idea, need to think about it. But anyways, this is separate task
>>
>
> May or may not be a separate task. But definitely bigger in scope.
>
> Andrus
>
>
--
Andrey
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 24, 2009, at 5:14 PM, Andrey Razumovsky wrote:
>>
>>
>> So ... another attempt at abstract analysis (or an attempt at
>> unwinding my
>> memory...) IIRC the main difference between DO and PO is fault
>> handling - we
>> can store a Fault instance in a map, but not in a typed ivar. So
>> PO's have
>> no concepts of faults at all, and the lifecycle is different. DO
>> approach is
>> more lazy (it won't try to create even a placeholder collection
>> until the
>> property is accessed), and I prefer it to PO's. Wonder if when we
>> reconcile
>> that somehow, the rest will fall into place on its own??
>>
>> (E.g. for PO's, we generate extra boolean "fault" properties for each
>> relationship, that are checked on every property access?)
>>
>
> Nice idea, need to think about it. But anyways, this is separate task
May or may not be a separate task. But definitely bigger in scope.
Andrus
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>
> My question is - why
>>> can't we have "silent" addTargetDirectly and removeTargetDirectly for
>>> to-many properties? This will allow as to manage event cycles.
>>>
>>
>
> I guess we can. This should replace "addReverse" parameter in the
> appropriate method. Talking from memory here, I may not remember all the
> stumbling blocks there (or even the full cycle of property setting). So if
> you can make it work, excellent.
>
> Also to make sure we are talking about the same thing... The question is
> who will be the owner of these methods - Object itself (as in DO), a to-many
> collection, or to-many property descriptor? I am thinking "property
> descriptor" (and possibly an underlying collection).
>
>
to-many collection and to-many property descriptor I guess.
>
> For POJOs and DO's it can work same as non-silent one, and for ROPs it
>> will
>> differ
>>
>
> "directly" means it won't trip a DB operation. So ideally it should work
> the same for all..
>
>
"Directly" means it puts value directly to underlying collection (if any).
I'll see if there is solution for all.
>
> So ... another attempt at abstract analysis (or an attempt at unwinding my
> memory...) IIRC the main difference between DO and PO is fault handling - we
> can store a Fault instance in a map, but not in a typed ivar. So PO's have
> no concepts of faults at all, and the lifecycle is different. DO approach is
> more lazy (it won't try to create even a placeholder collection until the
> property is accessed), and I prefer it to PO's. Wonder if when we reconcile
> that somehow, the rest will fall into place on its own??
>
> (E.g. for PO's, we generate extra boolean "fault" properties for each
> relationship, that are checked on every property access?)
>
Nice idea, need to think about it. But anyways, this is separate task
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.org>.
>> My question is - why
>> can't we have "silent" addTargetDirectly and removeTargetDirectly for
>> to-many properties? This will allow as to manage event cycles.
I guess we can. This should replace "addReverse" parameter in the
appropriate method. Talking from memory here, I may not remember all
the stumbling blocks there (or even the full cycle of property
setting). So if you can make it work, excellent.
Also to make sure we are talking about the same thing... The question
is who will be the owner of these methods - Object itself (as in DO),
a to-many collection, or to-many property descriptor? I am thinking
"property descriptor" (and possibly an underlying collection).
> For POJOs and DO's it can work same as non-silent one, and for ROPs
> it will
> differ
"directly" means it won't trip a DB operation. So ideally it should
work the same for all..
So ... another attempt at abstract analysis (or an attempt at
unwinding my memory...) IIRC the main difference between DO and PO is
fault handling - we can store a Fault instance in a map, but not in a
typed ivar. So PO's have no concepts of faults at all, and the
lifecycle is different. DO approach is more lazy (it won't try to
create even a placeholder collection until the property is accessed),
and I prefer it to PO's. Wonder if when we reconcile that somehow, the
rest will fall into place on its own??
(E.g. for PO's, we generate extra boolean "fault" properties for each
relationship, that are checked on every property access?)
Andrus
On Nov 24, 2009, at 4:33 PM, Andrey Razumovsky wrote:
> For POJOs and DO's it can work same as non-silent one, and for ROPs
> it will
> differ
>
> 2009/11/24 Andrey Razumovsky <ra...@gmail.com>
>
>> Now returning to my main goal - it is to allow PersistentObject
>> subclasses
>> work correctly on server and cannot be done without changing
>> PersistentObjectHolder's event procession.
>> The only reason that we have those PropertyChangeProcessingStrategy
>> and
>> many threadLocals all around is that PersistentObject-collections
>> must
>> notify context unlike ToMany-collections. So, if we are setting
>> reverse arc
>> via add() or remove() we get infinite loops an other nasty things.
>> We already have readProperty/readPropertyDirectly pair for simple
>> properties, where readPropertyDirectly is "silent". My question is
>> - why
>> can't we have "silent" addTargetDirectly and removeTargetDirectly for
>> to-many properties? This will allow as to manage event cycles. I
>> think this
>> will eliminate threadlocals and make Cayenne code simpler and safer
>>
>
>
>
> --
> Andrey
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
For POJOs and DO's it can work same as non-silent one, and for ROPs it will
differ
2009/11/24 Andrey Razumovsky <ra...@gmail.com>
> Now returning to my main goal - it is to allow PersistentObject subclasses
> work correctly on server and cannot be done without changing
> PersistentObjectHolder's event procession.
> The only reason that we have those PropertyChangeProcessingStrategy and
> many threadLocals all around is that PersistentObject-collections must
> notify context unlike ToMany-collections. So, if we are setting reverse arc
> via add() or remove() we get infinite loops an other nasty things.
> We already have readProperty/readPropertyDirectly pair for simple
> properties, where readPropertyDirectly is "silent". My question is - why
> can't we have "silent" addTargetDirectly and removeTargetDirectly for
> to-many properties? This will allow as to manage event cycles. I think this
> will eliminate threadlocals and make Cayenne code simpler and safer
>
--
Andrey
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
Now returning to my main goal - it is to allow PersistentObject subclasses
work correctly on server and cannot be done without changing
PersistentObjectHolder's event procession.
The only reason that we have those PropertyChangeProcessingStrategy and many
threadLocals all around is that PersistentObject-collections must notify
context unlike ToMany-collections. So, if we are setting reverse arc via
add() or remove() we get infinite loops an other nasty things.
We already have readProperty/readPropertyDirectly pair for simple
properties, where readPropertyDirectly is "silent". My question is - why
can't we have "silent" addTargetDirectly and removeTargetDirectly for
to-many properties? This will allow as to manage event cycles. I think this
will eliminate threadlocals and make Cayenne code simpler and safer
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
2009/11/24 Andrus Adamchik <an...@objectstyle.org>
> So here is a high-level question - do you think we can use
> ClassDescriptor/Property abstraction *internally* to build a unified
> ObjectContext implementation for any kind of objects? This was the goal of
> the reflect package anyways.
>
>
I think yes. In future :) Because currently, say, DataObject defines some
processing that cannot be avaliable in other types due to "skin" nature of
other objects. Other types (e.g. ROP) don't use these processings, so there
were created quite a lot of classes for different handling of objects. I see
that code to be moved to utility class..
The major high-level question is - should be process *graphs* of all types
of objects somewhat identically. I think yes. I think that ThreadLocals,
ProperyChangeProcessingStrategies and many other things were created due to
lack of methods of "core" processing of graphs and objects.
If this is correct in essence, we unify different contexts. All other is a
matter of refactoring.
Maybe we're just talking about different things - let me just do a minor
step in my direction and upload what I have so that we could talk around the
code.
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.org>.
So here is a high-level question - do you think we can use
ClassDescriptor/Property abstraction *internally* to build a unified
ObjectContext implementation for any kind of objects? This was the
goal of the reflect package anyways.
> getEntityResolver
> ().getClassDescriptor(object.getObjectId().getEntityName());
> Too hard for user who does not know Cayenne internals I think
Fine, but we are talking about two different things here - how to
build a single context for DO and PO and how to build user interface
for some specific convenience tasks. Let's discuss those 2 things
separately.
Andrus
On Nov 24, 2009, at 1:37 PM, Andrey Razumovsky wrote:
> 2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>
>>
>> I did not, but I defined 3 different types of objects (ROP, POJO,
>> JPA) that
>> don't use this approach for setting reverse relationship. So that's
>> what I
>> mean by pluggable :-)
>>
>>
> And now I want at least ROP-like classes do use this approach as
> well (i
> mean what is contained inside "setToOneTarget" method). I just want to
> minimize duplicating the code. Alternatively, same code will be
> added to the
> places where we process those "different types".
>
>
>>
>> Property p = ClassDescriptor.getProperty(String);
>> p.readProperty(Object);
>> p.readPropertyDirectly(Object);
>>
>>
> ...and more lines to get ClassDescriptor:
>
> ClassDescriptor cd = object.getObjectContext().
>
> getEntityResolver
> ().getClassDescriptor(object.getObjectId().getEntityName());
> Too hard for user who does not know Cayenne internals I think
Re: Accessing object metadata and other utilities
Posted by Michael Gentry <mg...@masslight.net>.
I tend to not like abbreviations for the most part (a little peeve of
mine -- I fall into the "software is meant to be read, not written"
camp), so I'd vote for something more like "Cayenne" in the current
org.apache.cayenne.util package. Simple, direct, and to the point.
mrg
On Tue, Nov 24, 2009 at 6:53 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> [As suggested in the parent thread, forking a new thread]
>
> On Nov 24, 2009, at 1:41 PM, Robert Zeigler wrote:
>
>> I'll second that. I ran into a very similar use case yesterday in a
>> hibernate project... I was wanting to get at hibernate's version of
>> ClassDescription, and it took me forever to track down the right way to do
>> it; once I knew how, it was simple enough, and just a few lines of code, but
>> I fear the above would cause a new Cayenne user the same level of
>> frustration I experienced yesterday with Hibernate. ;)
>
> I wouldn't mind if we add methods for ClassDescriptor lookups to the
> DataObjectUtils. BTW PersistentObject defines 'getObjEntity' method. I'd say
> we replace that with 'getClassDescriptor' and move it to a utility class.
>
> While we are at it, maybe rename DataObjectUtils to something more
> appropriate and shorter. CayenneUtil? Cayenne? ("Util" is already taken, and
> I'd rather it identify the origin of the framework).
>
> I sort of like calling it just "Cayenne" (for the same reasons of user
> simplicity), but then it implies this is a central class in the framework,
> and has more than just lookup-by-pk or give-me-metadata methods.
>
> Andrus
>
>
>
Re: Accessing object metadata and other utilities
Posted by Lachlan Deck <la...@gmail.com>.
On 24/11/2009, at 11:13 PM, Andrey Razumovsky wrote:
> or maybe PersistentUtils
+1 makes the most sense (to me at least) given it reflects the flavour of the interface to which these objects belong whether server-side or not.
> - because it will work with all types of
> classes (or at least those that implement Persistent).
with regards,
--
Lachlan Deck
Re: Accessing object metadata and other utilities
Posted by Andrey Razumovsky <ra...@gmail.com>.
Cayenne or maybe PersistentUtils - because it will work with all types of
classes (or at least those that implement Persistent).
Re: Accessing object metadata and other utilities
Posted by Robert Zeigler <ro...@roxanemy.com>.
CayUtils? I'm good with Cayenne, too.
Robert
On Nov 24, 2009, at 11/245:53 AM , Andrus Adamchik wrote:
> [As suggested in the parent thread, forking a new thread]
>
> On Nov 24, 2009, at 1:41 PM, Robert Zeigler wrote:
>
>> I'll second that. I ran into a very similar use case yesterday in a
>> hibernate project... I was wanting to get at hibernate's version of
>> ClassDescription, and it took me forever to track down the right
>> way to do it; once I knew how, it was simple enough, and just a few
>> lines of code, but I fear the above would cause a new Cayenne user
>> the same level of frustration I experienced yesterday with
>> Hibernate. ;)
>
> I wouldn't mind if we add methods for ClassDescriptor lookups to the
> DataObjectUtils. BTW PersistentObject defines 'getObjEntity' method.
> I'd say we replace that with 'getClassDescriptor' and move it to a
> utility class.
>
> While we are at it, maybe rename DataObjectUtils to something more
> appropriate and shorter. CayenneUtil? Cayenne? ("Util" is already
> taken, and I'd rather it identify the origin of the framework).
>
> I sort of like calling it just "Cayenne" (for the same reasons of
> user simplicity), but then it implies this is a central class in the
> framework, and has more than just lookup-by-pk or give-me-metadata
> methods.
>
> Andrus
>
>
Accessing object metadata and other utilities
Posted by Andrus Adamchik <an...@objectstyle.org>.
[As suggested in the parent thread, forking a new thread]
On Nov 24, 2009, at 1:41 PM, Robert Zeigler wrote:
> I'll second that. I ran into a very similar use case yesterday in a
> hibernate project... I was wanting to get at hibernate's version of
> ClassDescription, and it took me forever to track down the right way
> to do it; once I knew how, it was simple enough, and just a few
> lines of code, but I fear the above would cause a new Cayenne user
> the same level of frustration I experienced yesterday with
> Hibernate. ;)
I wouldn't mind if we add methods for ClassDescriptor lookups to the
DataObjectUtils. BTW PersistentObject defines 'getObjEntity' method.
I'd say we replace that with 'getClassDescriptor' and move it to a
utility class.
While we are at it, maybe rename DataObjectUtils to something more
appropriate and shorter. CayenneUtil? Cayenne? ("Util" is already
taken, and I'd rather it identify the origin of the framework).
I sort of like calling it just "Cayenne" (for the same reasons of user
simplicity), but then it implies this is a central class in the
framework, and has more than just lookup-by-pk or give-me-metadata
methods.
Andrus
Re: Nested ROP contexts and relationships
Posted by Robert Zeigler <ro...@roxanemy.com>.
On Nov 24, 2009, at 11/245:37 AM , Andrey Razumovsky wrote:
> 2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>
>>
>> I did not, but I defined 3 different types of objects (ROP, POJO,
>> JPA) that
>> don't use this approach for setting reverse relationship. So that's
>> what I
>> mean by pluggable :-)
>>
>>
> And now I want at least ROP-like classes do use this approach as
> well (i
> mean what is contained inside "setToOneTarget" method). I just want to
> minimize duplicating the code. Alternatively, same code will be
> added to the
> places where we process those "different types".
>
>
>>
>> Property p = ClassDescriptor.getProperty(String);
>> p.readProperty(Object);
>> p.readPropertyDirectly(Object);
>>
>>
> ...and more lines to get ClassDescriptor:
>
> ClassDescriptor cd = object.getObjectContext().
>
> getEntityResolver
> ().getClassDescriptor(object.getObjectId().getEntityName());
> Too hard for user who does not know Cayenne internals I think
I'll second that. I ran into a very similar use case yesterday in a
hibernate project... I was wanting to get at hibernate's version of
ClassDescription, and it took me forever to track down the right way
to do it; once I knew how, it was simple enough, and just a few lines
of code, but I fear the above would cause a new Cayenne user the same
level of frustration I experienced yesterday with Hibernate. ;)
Robert
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
2009/11/24 Andrus Adamchik <an...@objectstyle.org>
>
> I did not, but I defined 3 different types of objects (ROP, POJO, JPA) that
> don't use this approach for setting reverse relationship. So that's what I
> mean by pluggable :-)
>
>
And now I want at least ROP-like classes do use this approach as well (i
mean what is contained inside "setToOneTarget" method). I just want to
minimize duplicating the code. Alternatively, same code will be added to the
places where we process those "different types".
>
> Property p = ClassDescriptor.getProperty(String);
> p.readProperty(Object);
> p.readPropertyDirectly(Object);
>
>
...and more lines to get ClassDescriptor:
ClassDescriptor cd = object.getObjectContext().
getEntityResolver().getClassDescriptor(object.getObjectId().getEntityName());
Too hard for user who does not know Cayenne internals I think
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 24, 2009, at 1:20 PM, Andrey Razumovsky wrote:
> Have you
> ever overridden DataObject.setToOneTarget()?
I did not, but I defined 3 different types of objects (ROP, POJO, JPA)
that don't use this approach for setting reverse relationship. So
that's what I mean by pluggable :-)
>
> Anyways, at the minimum, as i mentioned somewhere before, i'd like
> to see
> something helper like DataObjectUtils.readProperty(Persistent,
> String) for
> simple and unified access to DO's properties any any tier
Property p = ClassDescriptor.getProperty(String);
p.readProperty(Object);
p.readPropertyDirectly(Object);
Andrus
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
2009/11/24 Andrus Adamchik <an...@objectstyle.org>
> 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.
>
>
Sure
>
> 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).
>
>
We should sort out *what* should be pluggable here. Property injection in
ever pluggable, and methods DataObject.setToOneTarget(...) (and I want it to
be DataObjectUtils.setToOneTarget(Persistent, ...)) is just a helper method
that calls those pluggable mechanisms. The need of setting reverse
relationships is a paramdigm and has no need to become pluggable. Have you
ever overridden DataObject.setToOneTarget()?
Anyways, at the minimum, as i mentioned somewhere before, i'd like to see
something helper like DataObjectUtils.readProperty(Persistent, String) for
simple and unified access to DO's properties any any tier
> 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 <an...@objectstyle.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 <an...@objectstyle.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
>>
>
>
--
Andrey
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@objectstyle.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 <an...@objectstyle.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
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
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 <an...@objectstyle.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 <an...@objectstyle.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
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.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 <an...@objectstyle.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
>>>
>
>
Re: Nested ROP contexts and relationships
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@objectstyle.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
>>
Re: Nested ROP contexts and relationships
Posted by Andrey Razumovsky <ra...@gmail.com>.
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 <an...@objectstyle.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
>