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: pass (hermes.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <004f01c4d965$297ae260$1401a8c0@rpws002>
From: "RPost" <rp0428@pacbell.net>
To: "Derby Development" <derby-dev@db.apache.org>
References: <1282959885.1101983902639.JavaMail.apache@nagoya>
 <41AF49C9.8090705@Mutagen.Net> <41AF71DB.8090506@debrunners.com>
 <41B09DAB.5060204@Mutagen.Net> <41B09F95.1040503@debrunners.com>
Subject: Re: [jira] Commented: (DERBY-13) Quoted names with embedded period
 mishandled in from list
Date: Fri, 3 Dec 2004 10:23:18 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I'm having trouble following this thread and know I could benefit by a brief
overview of the architecture of (at least) two things by anyone familiar
with the internals:

1. The database object architecture
2. The compiler architecture

As Dan pointed out DERBY-13 relates to a reported bug in the compiler
architecture whereas Jack's latest comment seems to be more related to the
object architecture itself.

Would someone volunteer to provide a brief overview of these two
architectures?

1. The database object architecture
  A. Schemas
      1) what are they?
      2) how do they relate to the other DB objects (users, tables,
procedures, etc). For example, are they containers that contain  or even
'own' the other objects or are they independent?
      3) how do DERBY schemas correlate to schemas found in Oracle or DB2 or
do they correlate?

  B. Tables
      1) what are they
      2) how do they relate to the other DB objects (particularly schemas).
      3) Must a table be 'contained' in a schema (as is required in DB2 or
Oracle)?
      4) how do DERBY tables correlate to tables found in Oracle or DB2 or
do they correlate?

My examination of the SQL-92 standard, the DERBY code, the DERBY-13 bug, and
tests with both Oracle (7, 8i, 9i, 10g) and DB2 (7 and 8) appears to show:

1. The tablename S1.T1 is a valid tablename (SQL standard, Oracle, DB2,
DERBY)
2. The tablename S1.T1 is stored in the system tables correctly (Oracle,
DB2, DERBY)
3. The tablename S1.T1 must be created, and can exist in one, and only one,
schema (Oracle, DB2)
       a. What is the rule for DERBY?

>From my tests I would conclude:

1. Schema and tablenames appear to be created properly in the DERBY system
tables.

2. The primary DERBY-13 issue is due to the compilers extraction and use of
the schema and tablenames and is not due to the names being improperly
stored in the repository.

3. The Java string manipulations being performed by DERBY on the schema and
table names is subject to error and, particularly in the 'Equals' methods',
incorrect in several places. In the case of the 'Equals' methods this is due
to the manner in which the Java '+' string concatenation operator, which is
implemented using string buffers, replaces 'null' elements with the string
'null'.

 This alone will cause the two 'Equals' methods that compare TableName
objects and use the getFullTablename  method of TableName to compare
differently than the 'Equals' method that performs a Java '+' string
contatenation. The first two methods perform tests for 'null' while the last
method does not.

4. I don't understand why two 'table name's would be considered equal if
only one of the schema names is null but the other has a value. Are they
only equal within the context of the compiler? Or are they considered equal
if stored in the repository that way? (or is it valid to store a table name
in the repository with a null schema?)

In summary, the architecture should seldom need to be changed to fix a 'bug'
as architecture changes introduce the potential to break far more things
than are fixed.

If, as Jack suggests, another method is needed to represent tablenames, a
new thread should be created to discuss it.

I agree with Dan that introducing a new tablename representation is outside
the scope of DERBY-13.

I don't think it is necessary to introduce a new representation since
tablenames are represented properly as strings as far as I can tell.

I always try to assume that an architecture is correct until proven
incorrect and I would expect that an explanation of the architecture of
schemas and tablenames would clear up any confusion that I have about why
they were designed this way.

I would be happy to work one on one (or in a group) with any of the
developers to begin to document the existing architecture and the design
decisions that went into it. This could be by telephone, email or in person
(I am in the San Francisco Bay area and would be happy to meet with folks on
this).


----- Original Message ----- 
From: "Daniel John Debrunner" <djd@debrunners.com>
To: "Derby Development" <derby-dev@db.apache.org>
Sent: Friday, December 03, 2004 9:17 AM
Subject: Re: [jira] Commented: (DERBY-13) Quoted names with embedded period
mishandled in from list


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jack Klebanoff wrote:
> > Daniel John Debrunner wrote:
> >
> >> Jack Klebanoff wrote:
> >>
> >>
> >> >Changing Derby to use a (schema, table) pair instead of a simple
string
> >> >for table names is a lot of work. A large number of files must be
> >> changed.
> >>
> >>
> >> But Derby doesn't use a simple string for a table name, it uses an
> >> object called TableName, which correctly handles the schema, table name
> >> and quoting. Only in this incorrect 'exposed' table name case is a
> >> string used.
> >>
> >> Dan.
> >
> >
> > TableName is a compiler object, and, as an extension of  QueryTreeNode,
> > it is a fairly heavy duty object tied to a connection. Outside of the
> > compiler transient data structures, and perhaps even some places inside
> > them, we need other mechanisms to represent table names.
>
> Ok, so you are talking about something beyond the scope of Derby-13,
> which is a compile time issue. So I'm  not sure what problem you are
> trying to solve as I thought that schema and table names were handled
> correctly through the runtime code, in terms of SchemaDescriptor and
> TableDescriptor objects.
>
> Maybe you have some example where a table name with schema is only
> represented by a String.
>
> Dan.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFBsJ+UIv0S4qsbfuQRApgRAJ9NQKbAlubCQz7fucM2GCl1fntXDQCfdIgy
> yvYoOulYYcSAujBLCjvK45c=
> =KHwm
> -----END PGP SIGNATURE-----
>