Re: Cayenne Operations Sorters

From: Andrus (andru..bjectstyle.org)
Date: Sun Jan 26 2003 - 21:34:30 EST

  • Next message: Holger Hoffstätte: "Re: New committer proposal: Andriy Shapochka"

    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