[
https://issues.apache.org/jira/browse/DERBY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461876
]
Yip Ng commented on DERBY-2183:
-------------------------------
Thanks Bryan for reviewing the patch! Let me attempt to answer your
questions/comments. =)
1) Yes, I agree that the Javadoc needs to be updated with regard to the
current changes.
I'll resubmit a follow up patch to address the code comments. In the
original code,
it appears that the SchemaDescriptor input parameter is never set even
though the
javadoc states so.
2) There are 3 possible values(of interest) that can get passed into
pushCompilerContext(SchemaDescriptor ):
a) A null SchemaDescriptor which indicates to the system to use the CURRENT
SCHEMA as the compilation
schema. (This is the same behavior as the original code.)
b) A SchemaDescriptor with its UUID == null, this means that either the schema
has not been physically
created yet or that the LCC's getDefaultSchema() is not yet up-to-date
with its actual UUID. Use the
CURRENT SCHEMA as the compilation schema. (This is the same behavior as
the original code.)
c) A schemaDescriptor with its UUID != null, this means that the schema has
been physiclally created.
Use this schema as the compilation schema (e.g.: for trigger or view
recompilation cases).
On a side note, if the check for UUID != null is removed, it will reveal
another bug in the view binding or execution code logic if the compilation
schema is set with case b) above. e.g.:
connect 'jdbc:derby:wombat;create=true' user 'user1';
create table ta (i int);
create view sva as select * from ta;
connect 'jdbc:derby:wombat' user 'user2';
create schema user2;
create view svc (i) as select * from user1.sva;
ERROR 42X05: Table/View 'TA' does not exist.
The cause for the above error is due to the view SVA's compilation schema UUID
being null
which is not correct, so setting compilation schema with case b) early has some
side effect
on the schema binding logic in later stage. It is probably due to a stale
default schema in LCC.
I think I'll file a separate jira for this issue. With the current fix, this
problem will
not manifest itself.
I'll add the above comments to the pushCompilerContext() javadoc also.
3) Actually, the view recompilation does not use
pushCompilerContext(SchemaDescriptor) directly but
instead sets the actual compilation schema to the compiler context
directly with a call
cc.setCompilerSchema(sd). This may explain why the problem does not occur
in view recompilation
cases. The comment is there to remind developers in the future to pay
attention when using LCC's
pushCompilerContext(SchemaDescriptor).
> Trigger recompilation problem when trigger action has its table not qualified
> with a schema
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-2183
> URL: https://issues.apache.org/jira/browse/DERBY-2183
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.0.0
> Environment: Any
> Reporter: Yip Ng
> Assigned To: Yip Ng
> Attachments: derby2813-trunk-diff01.txt, derby2813-trunk-stat01.txt
>
>
> Trigger recompilation problem when trigger action has its table not qualified
> with a schema.
> SPSs in SYS.SYSSTATEMENTS get invalidated for recompilation when
> sqlj.install_jar, sqlj.remove_jar, sqlj.replace_jar are called, or when a
> database upgrade is performed. The problem arises when the trigger action
> statement does not qualify the table with an explicit schema name. During
> recompilation it uses the default schema instead of using the original schema
> that was persisted in SYS.SYSSTATEMENTS causing an exception to occur. e.g.:
> C:\derby\trunk>java -classpath classes;. org.apache.derby.tools.ij
> ij version 10.3
> ij> connect 'jdbc:derby:wombat;create=true';
> ij> create table app.t1 (i int, j int);
> 0 rows inserted/updated/deleted
> ij> insert into app.t1 values (1,10);
> 1 row inserted/updated/deleted
> -- notice trigger action's update statement did not qualify table t1 with a
> schema name
> ij> create trigger app.tr1 after update of i on app.t1 update t1 set j = 1;
> 0 rows inserted/updated/deleted
> ij> update app.t1 set i=i+1;
> 1 row inserted/updated/deleted
> ij> select * from app.t1;
> I |J
> -----------------------
> 2 |1
> 1 row selected
> -- this action invalidates the SPS and mark for recompilation
> ij> call sqlj.install_jar('c:/derby/procs/Procs.jar', 'APP.Procs', 0);
> 0 rows inserted/updated/deleted
> ij> disconnect;
> ij> connect 'jdbc:derby:wombat' user 'user1';
> -- recompilation occurs but uses 'USER1' as the schema to compile instead of
> 'APP', resulting in error
> ij> update app.t1 set i=i+1;
> ERROR 42Y07: Schema 'USER1' does not exist
> ij>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
