At 02:21 AM 1/27/2003 +0200, Andriy Shapochka wrote:
>In brief, the whole commit thing works as follows (insertion case):
>1) Objects to insert are factorized by their belongings to ObjEntities and
>entities are grouped by nodes.
>2) RefIntegritySupport provides entity comparators to sort ObjEntities for
>each node.
>3) The sorted entity lists define the order in which lists of objects (per
>entity) are picked to form and run batches over JDBC connection (per node).
>
>This approach is different from that in the Cayenne classical commit where
>all the data objects (more precisely, queries) are sorted as members of one
>list (knowing that mergesort performance is of the n*log n class, one can
>easily compare the effectiveness of the two approaches).
I see... makes sense, but lets look at our current design and see how this
fits in the bigger picture (read: "I am dumb and can't figure out how to
port your design" :-)). A list of issues involved in ordering have recently
expanded to include (I don't know if Andriy is aware of the latest changes):
1. Insert/Delete order of dependent objects,
2. Insert/Delete order including reflexive relationships.
3. Delete/Update order for delete rules ("cascade", "nullify", "deny").
BTW, does "deny" throw an exception when triggered?
4. Handling inserts/deletes of the records in the join tables for flattened
relationships.
I understand that Craig introduced special ordering in DataContext for
cases 2..4 simply because our original implementation of (1) wasn't generic
enough (see Craig's comments in CVS DataContext, line 763)? I still believe
(but have no proof) that with the right implementation of sorting
(Ashwood?), 2..4 become subsets of (1). But looks like in addition to
working with entity dependency graph, we need an extra object dependency graph.
Another thing to consider is the current Cayenne design:
a. DataContext shouldn't do routing to nodes (DataDomain will)
b. DataDomain and DataNode should know nothing about DataObjects, and
especially relatonships between them. This is the reason I am passing query
objects from DataContext down.
c. Sort policies (on/off) should be set by node based on DbAdapter (if the
database doesn't care about constraints, we shouldn't too).
Given (c), we shouldn't ideally sort in the DataContext at all. At the same
time requirement (2) prompts otherwise. I wonder if we should use some
ordering hints on Queries (have a new "hint" field, maybe make it typed:
QueryHint, OrderingHint extends QueryHint?). Can use them for other things
in the future too...
As for Andriy's suggestion to separate queries by entities first, and sort
them after that, this can be done in the combined sorting algorithm at the
node level.
Andriy, what do you think? Are we on the same page, or still talking about
different things?
(For the new "delete" rules explanation go here:)
http://objectstyle.org/cayenne/lists/cayenne-devel/2002/12/0055.html
> > I disagree. We must always assume that all relevant *Db* relationships are
> > present. Otherwise Cayenne will break in many other places. *Obj*
> > relationships is another story and it is up to the user to have them or
> > not. But DbRelationships must be there.
> >
>I agree with you on this thing at the utmost degree if it is stated clearly
>in the product spec that the metadata describing the referential constraints
>must be present in the data map for Cayenne to handle the data modifications
>correctly and if an additional attribute is introduced for db-relationship
>to tell Cayenne whether it stands for the underlying foreign key or not.
DbRelationship *is* a foreign key. Even if the corresponding constraint is
not defined, it is a "logical" FK. I guess at some point we can start
making this distinction, but for now I suggest ignoring it. If the database
does not support FK (MySQL), then DbAdapter allows globally switching
ordering off.
Andrus
This archive was generated by hypermail 2.0.0 : Sun Jan 26 2003 - 21:34:23 EST