----- Original Message -----
From: "Andrus Adamchik" <andru..bjectstyle.org>
To: "Cayenne Devel" <cayenne-deve..bjectstyle.org>
Sent: Saturday, December 20, 2003 6:48 AM
Subject: Object Graph Refreshing: design ideas?
> 2. Track individual relationship modifications:
>
> This is a more subtle approach. Instead of invalidating the whole trees
> of objects, we can pinpoint a place where an object was removed or
> added and act accordingly.
>
> This is the choices that I see... Ideas? Comments?
>
> Andrus
>
What would you say about passing the info "those and those *DbRelationships*
changed." First, all our ObjRelationships are always based on
DbRelationships. Second, if a data row for a given DbEntity gets modified
(deleted) we should always be able to track which DbRelationships get
affected by this modification, just like any relational database engine can
instantly recognaze an FK->PK relationship is modified when a participating
table is edited. Thus, we can transfer the information what DbRelationships
are participating in the change happening to the DataRowStore in question.
This means we do not have to share any "Object-Relationship-Oriented"
knowledge with the DataRowStore firing this event. The listeners located in
the other VM's receive the event and look for the recorded in it
DbRelationship changes. What they do next, they find all the
ObjRelationships based on those DbRelationships and do something to them,
which may be coarse-grained relationship invalidation or fine-grained per
participating data object modification.
This is, of course, just a general idea, good, if it helps. For my part, I
am not very happy with 1. "Kill Them All, Let God Sort Them Out", since it
often subjects to cause huge collateral damage.
Andriy.
This archive was generated by hypermail 2.0.0 : Mon Dec 22 2003 - 06:29:57 EST