Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 4 Oct 2013 16:15:42 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12671616.1380645835060.14468.1380903342447@arcas>
In-Reply-To: <JIRA.12671616.1380645835060@arcas>
References: <JIRA.12671616.1380645835060@arcas>
Subject: [jira] [Commented] (DERBY-6361) Valid statements rejected if Derby
 has not implicitly created the current user's schema.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786283#comment-13786283 ] 

Knut Anders Hatlen commented on DERBY-6361:
-------------------------------------------

I'm wondering if one possible fix could be to change the aforementioned getSchemaDescriptor() call in DMLModStatementNode.parseAndBindGenerationClauses() so that its second argument is false. Then it will return null instead of failing. If it returns null, we don't push the compilation schema.

I think it should work because the generated update statement does not have any dependencies on the original compilation schema if it doesn't exist. Either the original schema didn't exist at CREATE TABLE/ALTER TABLE time, and then the CREATE TABLE/ALTER TABLE statement couldn't possibly have referenced anything in that schema. Or the original schema was dropped after the original CREATE TABLE/ALTER TABLE, and the dependency manager wouldn't allow the schema to be dropped if the generated column depended on the schema.

> Valid statements rejected if Derby has not implicitly created the current user's schema.
> ----------------------------------------------------------------------------------------
>
>                 Key: DERBY-6361
>                 URL: https://issues.apache.org/jira/browse/DERBY-6361
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-6361-01-aa-createDefaultSchema.diff
>
>
> There are many examples of statements failing because Derby has not implicitly created the schema associated with the current user. You don't see this if the schema is the default APP schema. But if the user is anyone other than APP, then various statements can fail. Maybe we should implicitly create a schema even if the user isn't APP. Right now, you get an error like this:
> ERROR 42Y07: Schema 'ROOT' does not exist
> The following script shows an example of this problem:
> connect 'jdbc:derby:memory:db;create=true;user=esq';
> create table licreq( domain varchar( 10 ) );
> connect 'jdbc:derby:memory:db;user=root';
> -- fails
> ALTER TABLE esq.licreq ADD COLUMN u_domain GENERATED ALWAYS AS (UPPER(domain));
> connect 'jdbc:derby:memory:db;user=app';
> -- succeeds
> ALTER TABLE esq.licreq ADD COLUMN u_domain GENERATED ALWAYS AS (UPPER(domain));


--
This message was sent by Atlassian JIRA
(v6.1#6144)