db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: [PATCH] Synonym support in Derby.
Date Sun, 05 Jun 2005 21:27:53 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
See comments below. Thanks for the review!<br>
Daniel John Debrunner wrote:<br>
<blockquote cite="mid42A0D763.3080805@debrunners.com" type="cite">
  <pre wrap="">- 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-&gt;A - dropped but not committed.

   B-&gt;C - dropped but not committed.

Then the other user rolls back the drop of B
This is not possible.&nbsp; When the second user attemps C -&gt; A, the
current code in createAliasConstantAction tries to resolve A to B and
then gets blocked trying to get AliasDescriptor for B. There is already
synonym cycle detection code, which blocks trying to get
AliasDescriptor for B and eventually times-out.<br>
<blockquote cite="mid42A0D763.3080805@debrunners.com" type="cite">
  <pre wrap="">- 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
While there is no harm in allowing DROP SYNONYM in soft upgrade mode, I
think it is better to raise the same error as CREATE SYNOYM. It would
seem odd that DROP SYNONYM would be "accepted" after soft upgrade, but
not CREATE SYNONYM. It is better to raise the same error message to say
database needs hard upgrade, I think.<br>
<blockquote cite="mid42A0D763.3080805@debrunners.com" type="cite">
  <pre wrap="">- 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?
These are changed now. I don't dislike repetitive, but don't mind
changing to circular.<br>
Next two should be solved by adding a row to SYSTABLES too. I will use
same order of access to catalogs, SYSTABLES followed by SYSALIASES (for
synonym) for both create table and create synonym statements. Hopefully
this should avoid any locking issues when the rows are not cached.<br>
I have also changed <b>dblook </b>to recognise synonyms. I will
attach the patch to Jira and <b>commit </b>it on <b>Monday at around
noon time</b> (Pacific Time) if there are no other comments. I can
address any comments received later as a separate patch, if needed.<br>
<blockquote cite="mid42A0D763.3080805@debrunners.com" type="cite">
  <pre wrap="">


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