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 <[email protected]>
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
