[
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)
