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: <42AB5AC4.9070201@debrunners.com>
Date: Sat, 11 Jun 2005 14:42:28 -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: 10.1 branch created / please review open 10.1 JIRA issues
References: <155E5416-F701-4485-BB21-290405E0A261@gmail.com>
 <d8blp4$d5v$1@sea.gmane.org> <22B2C628-2138-42D2-81E9-3881E0CABAE0@gmail.com>
 <d8e6k4$b21$1@sea.gmane.org> <42AAFACD.8080705@debrunners.com>
 <d8f7kq$knu$1@sea.gmane.org> <x1o3mzpwbthq.fsf@atum10.Norway.Sun.COM>
 <d8fk56$ncl$1@sea.gmane.org>
In-Reply-To: <d8fk56$ncl$1@sea.gmane.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter Nabbefeld wrote:

>>
> I've looked at it. As I've seen, LLC supports only to get the default
> schema (so it seems to be difficult to get a non-default schema for
> compilation; probably "getSchema(String name)" should be added to LLC).

No, code gets schema descriptors all the time during compilation, there
are methods to get a schema desciptor from a name in QueryTreeNode,
which is the root class for all compilation nodes.

Since Java is an o-o language there is no need to add get methods for
everything to the LCC, instead the LCC provides methods to get the
object that manages the entity. For schemas, tables etc. the object is
the DataDictionary, thus that class has the get methods for various
catlog entries.


> However, if there is no default user schema, default schema should be
> "APP", not null (if I've understood the comment for "protected
> SchemaDescriptor initDefaultSchemaDescriptor() ..." in
> GenericLanguageConnectionContext correct).

The default schema is a schema name corresponding to the user name if
the connection has not executed a SET SCHEMA statement. In Derby if that
schema has not been created, then the current schema is still that
schema, even though it doesn't exist. The schema descriptor representing
this "virtual" schema will have a null UUID, indicating it is not
persistent. The APP is the default user name, not the default schema
name, though the comments in some areas of the code are misleading on
this. Also I think the concept of a "default" schema is wrong, I think
the code should refer to the "current" schema. Since once a connection
has performed a SET SCHEMA then there is no notion of a default schema.
There is no way to get back to the original schema without an explict
set schema with the name, nothing default about this.

Not sure if this is relevant to this bug or not, I haven't looked at it.
The bug may be more related to if a SQL statement does not depend on the
current schema, ie. all names are schema qualified, then its compilation
schema is null. The code that persists a trigger may then not be coded
to handle a null compliation schema.

Dan.