>> 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 <razumovsky.andre..mail.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
This archive was generated by hypermail 2.0.0 : Tue Nov 24 2009 - 09:55:06 EST