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