[DERBY-6361] Valid statements rejected if Derby has not implicitly created the current user's schema.

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 10.8.3.3, 10.9.2.2, 10.10.2.0, 10.11.1.1
• Component/s: SQL
• Urgency: Normal
• Issue & fix info: Repro attached
• Bug behavior facts: Seen in production
• Assignee: Richard N. Hillegas
• Reporter: Richard N. Hillegas
• Created: 01/Oct/13 16:43
• Updated: 21/Jan/15 00:23
• Resolved: 06/Mar/14 00:11

Description

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

Issue Links

• Is contained by: DERBY-6498 Derby does not always automatically create a user's schema
• is related to: DERBY-6481 Derby 10.10 backport issue (winter/spring 2014)
• relates to: DERBY-5139 User schema not auto-created on creation of self-referencing table
• relates to: DERBY-3945 Generation clauses which mention user-coded functions may produce different resuls depending on who performs the triggering INSERT/UPDATE
• relates to: DERBY-3270 Delayed (on-demand) creation of current user schema makes select from view belonging to other schema fail.