Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42A0D763.3080805@debrunners.com>
Date: Fri, 03 Jun 2005 15:19:15 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [PATCH] Synonym support in Derby.
References: <429D86BB.9030804@Sourcery.Org> <429E6D69.7060103@Sourcery.Org>
In-Reply-To: <429E6D69.7060103@Sourcery.Org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

- 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.