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: <41AE4157.5020209@debrunners.com>
Date: Wed, 01 Dec 2004 14:10:31 -0800
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4.1) Gecko/20031008
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [jira] Created: (DERBY-85) NPE when creating a trigger on a table
 and default schema doesn't exist.
References: <1283329719.1101867088475.JavaMail.apache@nagoya>
 <41AE1DF5.9010209@golux.com>
In-Reply-To: <41AE1DF5.9010209@golux.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Army wrote:

> A B (JIRA) wrote:
>
>> NPE when creating a trigger on a table and default schema doesn't
>> exist.
>> ------------------------------------------------------------------------
>
> [ snip ]
>
>>
>> A look at the derby.log file shows the stack trace given below.  In a
>> word, it looks like the "compilation schema"
>> field of SYS.SYSTRIGGERS isn't getting set, and so it ends up being
>> null.  That causes the NPE in subsequent
>> processing...
>
> [ snip ]
>
> The compilation schema for a trigger is set to "current schema" at the
> time the trigger is created.  In the repro given for this bug, "current
> schema" is (by default) "SOMEUSER",  but since that schema doesn't
> exist, it looks like we end up setting compilation schema to null.
>
> So, which of the following would be the preferred fix?
>
> 1) Force the implicit creation of "current schema" if it doesn't exist,
> and _then_ set compilation schema to "current schema"?
>
> 2) Set "compilation schema" to something other than "current schema" if
> "current schema" doesn't exist?  What would we use, then?
>
> 3) Leave "compilation schema" null, and add logic to check for it and
> behave appropriately?  What exactly "appropriately" means would depend
> on the context...(this seems like a faulty approach, but I thought I'd
> mention it...).
>
> 4) Something else entirely?

I think 3) is correct.

A null compilation schema for a trigger, or any statement after
compilation indicates that the statement had no dependency on the
current schema, that is, there are non-schema qualified identifiers in
the statement's text. This null compilation schema will be used by the
statement cache to allow plan sharing across connections that are in
different schemas.

So in the trigger case it is safe to compile the trigger in any schema
if its stored compilation schema is null, since it has no dependency on
being compiled in a specific schema.

Dan.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBrkFWIv0S4qsbfuQRAl7HAJ9sCT9D++mHci/YL2LtqtTpYP+mVACfaYek
yCUqFUjwN6JOfSqNVzX+3vM=
=eJNM
-----END PGP SIGNATURE-----