Re: Cayenne Operations Sorters

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

  • Next message: Andrus: "Merging Cayenne-Andriy with Cayenne :-)"

    At 01:49 PM 1/26/2003 +0200, Andriy Shapochka wrote:
    > > is to split the solution between DefaultSorter and Ashwood's Table. Table
    > > will tell that it does indeed have the reflexive relationships, while
    > > DefaultSorter will take this into account in its DataObjectComparator.
    > > Andriy, do you think this is doable?
    >
    >Actually, the RefIntegritySupport and ContextCommit classes were designed
    >with the possibility of such an inclusion of additional logic in mind. To
    >add an ability to resolve reflexive relationships all one has to do is to
    >apply this new algorithm to the lists of objects factorized by ObjEntity
    >(ContextCommit.newObjectsByObjEntity variable) in the
    >ContextCommit.prepareInsertQueries, ContextCommit.prepareDeleteQueries
    >methods.

    Let me explain to others, ContextCommit is Andriy's alternative to our mess
    in DataContext.commitChanges(). I haven't looked at it just yet.

    But lets do things one step at a time... With this philosophy in mind, is
    it still possible to do the reflexive stuff in
    DefaultSorter.DataObjectComparator?

    > > 2. Andriy's code initializes net.ash.dbutil.Table instances partially
    >using
    > > JDBC MetaData, partially - Cayenne DataMap. Andriy, how hard is it to add
    > > API to use DbEntity relationships as opposed to retrieving PK/FK
    > > information via JDBC on every run (which is quiet an overhead, esp. given
    > > that this information is already in the relationships)?
    >
    >Well, at first I had thought to do this very thing, use the information
    >stored in the data map to build a graph. As a matter of fact, my further
    >development of the testing application proved data map traversals quite easy
    >and convenient. But there is a very serious problem with the data maps. You
    >see, generally, a developer is not required to put explicitly all necessary
    >referential integrity information into the data map, indeed, one could
    >prefer not to introduce a relationship between two entities, the foreign key
    >being defined in the database, but work with their attributes instead,
    >manually assigning the correct values to conform referential integrity
    >requirements.

    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.

    IMO the mapping must be the main and the only source of database *runtime*
    information. Initial reverse engineering should be the time and place to
    read DB metadata. If the database changes and the mapping is not updated,
    it is absolutely correct and acceptable behavior for Cayenne to throw an
    exception, and not trying to guess what those changes might be about.

    Again, having better database synchronization features in the GUI to help
    solving such problems will be a good thing, and we should look at this in
    the future, but no synchronizing in runtime... (BTW, it takes about 7-10
    min to reverse engineer the Oracle schema for one of my customers...)

    >On the other hand, oftentimes a developer
    >would define a relationship between two entities without the underlying
    >RDBMS constraint at all (in the worst case of MySQL and likes, the
    >referential integrity is not supported).

    MySQL adapter returns NULL sorter, so this is handled already.

    Andrus



    This archive was generated by hypermail 2.0.0 : Sun Jan 26 2003 - 18:06:20 EST