Fine, the things are definitely advancing!
> solution. BTW, Andriy, are you planning on renaming Java packages from
> net.ash to org.objectstyle.ahswood?
Very good point. I missed this one somehow. Will rename the packages asap.
>
> 1. org.objectstyle.cayenne.access.util.SortHandler is a cleaner and more
> generic version of OperationSorter. Once we switch, OperationSorter will
> become deprecated and replaced by SortHandler.
>
> 2. org.objectstyle.cayenne.access.util.DependencySorter is an interface of
> a sort algorithm. It decouples SortHandler from the algorithm
implementation.
>
> 3. org.objectstyle.cayenne.access.util.DefaultSorter - an implementation
of
> DependencySorter. This was directly ported from Andriy's
> RefIntegritySupport class (Andriy has his own version of Cayenne that
> deviated from ours, and now we are working to bring them together).
Yep, this is, of course, more consistent to organize the referential
integrity support code taking into account the existing architecture. I did
not go this way at once in order to maximally separate the new code and thus
make the following integration easier.
> 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.
>
> 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. One should agree it is easy to come up with examples this
scenario would be appropriate for. 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). Still, Cayenne is always
anticipated to commit the data modifications correctly, as a developer
cannot affect the insertion and deletion ordering by hand. The information
taken from the data map, in the former case we would have ended up with
commit failures because of the missing relationships, and the latter one
would have led us to operating with redundant relationships and, knowing the
nature of the algorithms applicable, one can construct quite realistic
examples of the database schemas conforming the requirement of acyclicness
on which commits would have failed owing to the redundancy, not mentioning
possible overhead.
Now, yes, I completely agree with you - reading metadata eats up performance
like hell, but it seems to me much lesser evil in comparison with commit
failures, besides the metadata is cached in my version of Cayenne, a commit
running first against the corresponding data node, so it is not a problem
for apps with lifetime more then a couple of commits. The conclusion is one
cannot rely on data maps to truly support referential constraints in their
current condition, only to find out which tables in the database schema must
be heeded. It is preferable to invent better way to persist the actual
metadata retrieved from the database automatically so that to read it as
seldom as possible, but (emphasis) the metadata must be sufficient and
concerning the actually defined foreign keys only!
Andriy.
This archive was generated by hypermail 2.0.0 : Sun Jan 26 2003 - 13:13:36 EST