- 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?
E.g.
A->B
B->A - dropped but not committed.
A->B
B->C - dropped but not committed.
C->A
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?
- OTHER
---
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)';
CREATE SYNONYM T1;
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
entry?
Dan.
