[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783197#comment-13783197 ] Rick Hillegas commented on DERBY-6361: -- The generated column seems to be part of the problem. The following ALTER TABLE statement works: ALTER TABLE esq.licreq ADD COLUMN u_domain int; > 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 > > 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[
https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783746#comment-13783746
]
Knut Anders Hatlen commented on DERBY-6361:
---
The generated UPDATE statement doesn't have any unqualified names, and doesn't
reference the ROOT schema, so it should be able the compile even if there is no
ROOT schema. The reason why it fails, seems to be that
DMLModStatementNode.parseAndBindGenerationClauses() sets the compilation schema
to the current schema at the time of the ALTER TABLE statement that added the
generated column:
{code}
//
// Unqualified function references should resolve to the
// current schema at the time that the table was
// created/altered. See DERBY-3945.
//
SchemaDescriptororiginalCurrentSchema =
getSchemaDescriptor( di.getOriginalCurrentSchema(), true );
compilerContext.pushCompilationSchema( originalCurrentSchema );
{code}
This also seems to cause problems when the generated column is added by CREATE
TABLE from a non-existing schema, but the error won't be seen until you try to
add rows to that table:
{noformat}
ij version 10.11
ij> connect 'jdbc:derby:memory:db;create=true;user=root';
ij> create table app.t1(x int, y int generated always as (-x));
0 rows inserted/updated/deleted
ij> insert into app.t1(x) values 1,2,3;
ERROR 42Y07: Schema 'ROOT' does not exist (errorCode = 3)
ij> connect 'jdbc:derby:memory:db;user=app';
ij(CONNECTION1)> insert into app.t1(x) values 1,2,3;
ERROR 42Y07: Schema 'ROOT' does not exist (errorCode = 3)
{noformat}
This also fails with the patch, by the way.
> 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784211#comment-13784211 ] Rick Hillegas commented on DERBY-6361: -- A more general solution might involve automatically creating schemas for new users at connection time provided that the user is not a read-only user and the database is not read-only. This won't plug all holes. For instance, what happens if the user drops their schema and then issues the INSERT in the previous example which Knut gave. > 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784238#comment-13784238 ] Rick Hillegas commented on DERBY-6361: -- Tests passed cleanly for me on derby-6361-01-aa-createDefaultSchema.diff. I will hold off committing this patch, however, since a more general solution may be possible. > 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786524#comment-13786524 ] Rick Hillegas commented on DERBY-6361: -- That might finesse the problem. Alternatively, if we can convince ourselves that CHECK constraints, generation clauses, and defaults should be compiled in the schema which holds the table (see DERBY-6362), then we can push that schema instead of the current (possibly non-existent) schema. Thanks. > 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790119#comment-13790119 ] Knut Anders Hatlen commented on DERBY-6361: --- GLCC.pushCompilerContext() already handles the case where the SchemaDescriptor is null, by the way, so we probably don't need to make DMLModStatementNode.parseAndBindGenerationClauses() check for null and skip pushing in that case. Simply changing the second argument to the getSchemaDescriptor() call should be enough, I think, but I haven't tested it. > 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797140#comment-13797140 ] Rick Hillegas commented on DERBY-6361: -- Thanks, Knut. Looks good to me. +1 > 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: d6361-ignore-missing-schema.diff, > 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797694#comment-13797694 ] ASF subversion and git services commented on DERBY-6361: Commit 1532997 from [~knutanders] in branch 'code/trunk' [ https://svn.apache.org/r1532997 ] DERBY-6361: Valid statements rejected if Derby has not implicitly created the current user's schema. Make compilation of the generation clause accept that the original compilation schema does not exist. > 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: d6361-ignore-missing-schema.diff, > 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)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905966#comment-13905966 ] Mike Matrigali commented on DERBY-6361: --- Is this issue fixed now in trunk? does it make sense to put this in 10.10? > 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: d6361-ignore-missing-schema.diff, > 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.5#6160)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905987#comment-13905987 ] Rick Hillegas commented on DERBY-6361: -- Hi Mike, I think we're going to stumble across other instances of this problem. But 1532997 could be backported and that would be incremental progress. Thanks. > 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: d6361-ignore-missing-schema.diff, > 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.5#6160)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906244#comment-13906244 ] Mike Matrigali commented on DERBY-6361: --- would it be ok to close this one as fixed,as at least the fix addresses the referenced test case. And then open new ones and link as we find new issues? > 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: d6361-ignore-missing-schema.diff, > 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.5#6160)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906514#comment-13906514 ] Rick Hillegas commented on DERBY-6361: -- We could do that if the open issue bothers people. But the reason that I opened a generic issue was because I wanted to avoid filing a new issue for each instance of this problem. I regard it as a systemic problem which ultimately needs a systemic solution. Thanks. > 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: d6361-ignore-missing-schema.diff, > 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.5#6160)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921683#comment-13921683 ] Myrna van Lunteren commented on DERBY-6361: --- I understand your concern Rick. But I went ahead to open another issue, DERBY-6498, because this one has fixes connected to it that I would like to backport, and as it is, it's not showing up for release notes and our backport (to 10.10) query because it's not resolved/closed... > 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 > Fix For: 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13924136#comment-13924136 ] Mamta A. Satoor commented on DERBY-6361: Assigning to me temporarily while I backport it. > 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: Mamta A. Satoor > Fix For: 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13924246#comment-13924246 ] Mamta A. Satoor commented on DERBY-6361: I will look further into following failure but after doing a merge to 10.10 codeline, when I compile the code using ant clobber, ant clean and ant all, ant all gives following error [javac] C:\p4clients\svn10.10\client1\10.10\java\testing\org\apache\derbyTesting\functionTests\tests\lang\GeneratedColumnsTest.java:5640: getSchemas() in java.sql.DatabaseMetaData cannot be applied to (,java.lang.String) [javac] JDBC.assertEmpty(conn.getMetaData().getSchemas(null, user)); [javac]^ [javac] C:\p4clients\svn10.10\client1\10.10\java\testing\org\apache\derbyTesting\functionTests\tests\lang\GeneratedColumnsTest.java:5659: getSchemas() in java.sql.DatabaseMetaData cannot be applied to (,java.lang.String) [javac] JDBC.assertEmpty(conn.getMetaData().getSchemas(null, user)); [javac]^ [javac] 2 errors > 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: Mamta A. Satoor > Fix For: 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13924434#comment-13924434 ] Mamta A. Satoor commented on DERBY-6361: Issue appears to be with lang/build.xml in 10.10 because that build.xml does not compile any test in lang directory with jdk1.6. In trunk, all the lang tests get compiled with jdk1.6 and hence DatabaseMetadData.getSchemas(String, String) call(which was introduced in jdk 1.6) gets compiled correctly in trunk. I am working on changing the build.xml in 10.10 lang directory to allow GeneratedColumnsTest.java to be compiled with jdk1.6 so we will not throw a compile time error for DatabaseMetadData.getSchemas(String, String) call made by the new junit fixture in GeneratedColumnsTest.java > 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: Mamta A. Satoor > Fix For: 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925062#comment-13925062 ] ASF subversion and git services commented on DERBY-6361: Commit 1575635 from [~mamtas] in branch 'code/branches/10.10' [ https://svn.apache.org/r1575635 ] DERBY-6361(Valid statements rejected if Derby has not implicitly created the current user's schema.) Backporting to 10.10 > 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: Mamta A. Satoor > Fix For: 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925482#comment-13925482 ] ASF subversion and git services commented on DERBY-6361: Commit 1575839 from [~mamtas] in branch 'code/branches/10.9' [ https://svn.apache.org/r1575839 ] DERBY-6361(Valid statements rejected if Derby has not implicitly created the current user's schema.) Backporting to 10.9 > 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: Mamta A. Satoor > Fix For: 10.10.1.4, 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925523#comment-13925523 ] Knut Anders Hatlen commented on DERBY-6361: --- The changes in the backport seems to have broken the tests on Java 5, because the classes cannot be loaded on that platform if they have been compiled with target level 1.6. I think a better way to port the test case would be to make it use the getSchemas() method instead of getSchemas(String,String), as the former is also available in earlier JDBC versions. > 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: Mamta A. Satoor > Fix For: 10.9.2.2, 10.10.1.4, 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925528#comment-13925528 ] ASF subversion and git services commented on DERBY-6361: Commit 1575862 from [~knutanders] in branch 'code/branches/10.10' [ https://svn.apache.org/r1575862 ] DERBY-6361: Fix UnsupportedClassVersionError when running tests on Java 5 > 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: Mamta A. Satoor > Fix For: 10.9.2.2, 10.10.1.4, 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925715#comment-13925715 ] ASF subversion and git services commented on DERBY-6361: Commit 1575933 from [~knutanders] in branch 'code/branches/10.9' [ https://svn.apache.org/r1575933 ] DERBY-6361: Fix UnsupportedClassVersionError when running tests on Java 5 Merged revision 1575862 from 10.10. > 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: Mamta A. Satoor > Fix For: 10.9.2.2, 10.10.1.4, 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930694#comment-13930694 ] ASF subversion and git services commented on DERBY-6361: Commit 1576449 from [~mamtas] in branch 'code/branches/10.8' [ https://svn.apache.org/r1576449 ] DERBY-6361(Valid statements rejected if Derby has not implicitly created the current user's schema.) Backporting to 10.8 > 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: Mamta A. Satoor > Fix For: 10.8.3.3, 10.9.2.2, 10.10.1.4, 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930709#comment-13930709 ] Mamta A. Satoor commented on DERBY-6361: Finished backporting upto 10.8 I do not plan to backport further at this point. Reassigned the issue to Rick. > 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 > Fix For: 10.8.3.3, 10.9.2.2, 10.10.1.4, 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931558#comment-13931558 ] ASF subversion and git services commented on DERBY-6361: Commit 1576655 from [~knutanders] in branch 'code/branches/10.8' [ https://svn.apache.org/r1576655 ] DERBY-6361: Fix UnsupportedClassVersionError when running tests on Java 5 Merged revision 1575933 from 10.9. > 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 > Fix For: 10.8.3.3, 10.9.2.2, 10.10.1.4, 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
[jira] [Commented] (DERBY-6361) Valid statements rejected if Derby has not implicitly created the current user's schema.
[ https://issues.apache.org/jira/browse/DERBY-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13932755#comment-13932755 ] Mamta A. Satoor commented on DERBY-6361: Knut, thanks for fixing the test by making it not use Java 6 call which will fail when the test is run with Java 5. > 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 > Fix For: 10.8.3.3, 10.9.2.2, 10.10.1.4, 10.11.0.0 > > Attachments: d6361-ignore-missing-schema.diff, > 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.2#6252)
