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?
Sorry if these sound naive or confused but I'm not really such a DBA
hotshot :)
Holger
BTW: reenginering from HSQLDB works :)
This archive was generated by hypermail 2.0.0 : Thu Feb 13 2003 - 13:35:41 EST