db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: more on system schema vs. user schema and character constants.
Date Thu, 31 May 2007 18:03:44 GMT
Mamta Satoor wrote:
> Dan, I am trying to understand the difference between connection's 
> current schema vs compilation schema of a statement. It will help me a 
> lot if you could talk about the 2 schemas in reference to an example.

set schema A
create view V as select * from T
set schema B
select * from A.V

When executing the last statement (select from the view) the 
connection's current schema  and the compilation schema for the 
statement is B, but the views select needs to be compiled in schema A to 
ensure that T resolves to A.T as the creator of V intended. Derby 
supports nesting of compilation contexts and that is where the current 
compilation schema is defined.

Views are compiled when used, the tree for the view is created and then 
merged with the tree containing the view. There is no pre-compiled plan 
for a view.

Trigger action statements do have a pre-compiled plan but can be 
recompiled when used due to factors such as an additional index being 
created. In that case the trigger's action statement much be compiled 
against its compilation schema and not the current schema of the 
connection. This ensures consistency of the trigger action.

Similar for stored prepared plans (SPS) which is how the meta-data 
queries (and trigger action statements :-) are implemented.


> thanks,
> Mamta
> On 5/30/07, *Daniel John Debrunner* <djd@apache.org 
> <mailto:djd@apache.org>> wrote:
>     Mike Matrigali wrote:
>      > I am sort of confused at this point, what we expect to be working
>      > now and what should be.  What is the right way to write the
>      > following query against a the system schema?  Is there anyway to
>      > write the query without changing the default schema? :
>     Not sure if it's related or not but I just noticed this code in CastNode
>     and there is other similar fragments elsewhere in ValueNodes.
>         //set the collation type to be same as the current schema's
>         //collation type. Collation derivation is already initialized
>         //to correct value by default which is "IMPLICIT"
>         getTypeServices().setCollationType(
>       getLanguageConnectionContext().getDefaultSchema().getCollationType());
>     I think this is incorrect. During compilation the correct value to get
>     the current schema is using the getSchemaDescriptor(null) call for any
>     node. The current schema for compilation will not match the connection's
>     current schema in some situations, such as compiling an action statement
>     for a trigger, a sps for metadata queries and possibly for views as
>     well.
>     If this code is frequent it might be worth creating a utility method in
>     ValueNode as
>     setSchemaCollation() {
>         getTypeServices().setCollationType(
>          getSchemaDescriptor(null).getCollationType());
>     }
>     Dan.

View raw message