db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [PATCH] Synonym support in Derby.
Date Fri, 03 Jun 2005 22:19:15 GMT
- QueryTreeNode.resolveTableToSynonym
 The for(;;) could use some comments as to why it won't loop forever
(circle of synonyms)
 Are there any issues with circular dependencies being caused by rollbacks?
   B->A - dropped but not committed.

   B->C - dropped but not committed.

Then the other user rolls back the drop of B

- sqlgrammar.jj - DROP SYNONYM
  No need for the checkVersion on the DROP, it doesn't create any
  on-disk artifacts that would cause problems in earlier releases

- Synonym alias info
    Copyright date needs to be just 2005
    Do we need the schema length in the toString(), why not separate
them with a dot, more readable, and include quoting?

- messages

01522 - why not 'newly created SYNONYM' rather than 'new created alias'?

42916 -   s/repetitive/circular/ ??? Any language experts out there?



I think more checking is need for the CREATE TABLE and CREATE VIEW to
ensure the name does not exist as a SYNONYM. Unless I missed it, you are
only performing the check at compile time, not runtime. A create
statement can be prepared and then execute later, e.g.

prepare CT as 'CREATE TABLE T1(I INT)';
execute CT;

These checks would be in the constant actions for these operations.


As you mentioned the potential for deadlocks or duplicate names on the
namespace across two tables (SYSTABLES and SYSALIAS) might exist. A lot
depends on when you request a table or alias descriptor from the data
dictionary is an actual lock held on the row, or is it a read committed
lock, or is it simply a cache lookup? Currently this is enforced at the
end of the day for tables and views by the unique index on SYSTABLES.

My guess is a stress test may hit problems with your approach.

My only thought on this would be to have a row in SYSTABLES for the
SYNONYM to ensure uniqeness, and a row in SYSALIASes. But that's just
off the top of my head, there may be similar problems with such an approach.


Is there a jira entry for this, could future patches be attached to that


View raw message