Let me add a touch as well. Yes, ashwood has enough functionality to handle
any referential integrity graph of data objects. Ashwood based commit(...)
correctly handles acyclic table dependencies and tables referencing
themselves. It also does its best to handle tables with cyclic referential
dependencies. But it is not guaranteed to succeed on such schemas. It is
doable but not done yet. Handling objects for tables with multiple foreing
keys pointing to themselves was the first step in this direction. Regression
tests and, as far as I understand, ref. integrity related JUnit tests are
passed by commit(...). But since there are several portability and minor
behavioral problems with commit(...) it has not become the standard
commitChanges(...) yet. I use it with my Oracle successfully though.
Therefore it is advised that using it and having cyclic referential
dependencies in the schema one should make the referential constraints
involved in the cycles DEFERRABLE. In case there are no cycles aside from
reflexive tables DEFERRABILITY is not needed.
> To add to the confusion, should I mention that we have 3 different sorters
> now (called different names), with changes added by Andriy, and my earlier
> attempts to integrate them. I will be working on merging them all together
> into something consistent.
>
> Current OperationSorter is rather naive and doesn't handle many cases
> correctly. When we completely migrate to Ashwood, this must be solved. I
> believe Ashwood based sorters handle all the issues.
>
> Now, the deferrable option. I suggest to make it just that - an option for
> SQL generation (of course for the databases that support it). Since this
> requires GUI changes and such, I suggest to ignore it for the Beta release
> and rely on sorter where possible. If this causes problems, we will fix
> the sorter (we need to switch it to Ashwood, like I said).
>
> In general, operation sorting should probably be handled via a delegate,
> with adapter providing a default sorter. Such delegate can override or
> disable sorter for cases like tables with deferred constraint checking.
> But this feature is very low priority, since having a sorter never hurts,
> maybe just slowing down things a bit on commit.
This archive was generated by hypermail 2.0.0 : Thu Feb 13 2003 - 15:37:47 EST