[
https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790133#comment-13790133
]
Knut Anders Hatlen commented on DERBY-6361:
-------------------------------------------
Or maybe not... DMLModStatementNode.parseAndBindGenerationClauses() uses
CompilerContext.pushCompilationSchema(), not
LanguageConnectionContext.pushCompilerContext(). I noticed the handling of
non-existent compilation schema in pushCompilerContext() while working on
DERBY-6371 and thought that was the same method used here, but apparently not.
> 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)
