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.
> I would like to better understand how the OperationSorter and DEFERRABLE
> INITIALLY DEFERRED might work together, or against each other.
> The current PostgreSQL adapter uses the DEFERRABLE clause for
> relationship constraints and this works great, but I'm not sure if this
> might have drawbacks? DEFERRABLE allows fk constraints to be temporarily
> inconsistent until the current transaction is committed, which is a nice
> way to achieve the same 'entity ordering' effect than with the OpSorter.
> It is also said to be slighly faster, OTOH I know some DBAs (or pointy
> haired managers) do not like this idea and I guess there might be
> scenarios where you want to have a constraint fail immediately. How does
> the OpSorter deal with cycles? Can they exist in practice? I just added
> an OpSorter to the PostgresAdapter and tested without DEFERRABLE; this
> worked just fine, as expected.
> If the OpSorter and DEFERRABLE can coexist, would it make sense to add
> this to the OracleAdapter as well, even though it might not be required?
> Or should I remove the DEFERRABLE option for Postgres, now that it has
> an OpSorter?
They can coexist, but I feel like "DEFERRABLE" shouldn't be a default option.
>
> BTW: reenginering from HSQLDB works :)
Cool!!
Andrus
This archive was generated by hypermail 2.0.0 : Thu Feb 13 2003 - 13:54:12 EST