db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-424) Queryplan for a query using SESSION schema view is incorrectly put in statement cache. This could cause incorrect plan getting executed later if a temp. table is created with that name.
Date Wed, 19 Oct 2005 05:13:45 GMT
     [ http://issues.apache.org/jira/browse/DERBY-424?page=all ]

Mamta A. Satoor updated DERBY-424:
----------------------------------

    Attachment: Derby424SessionSchemaCaching.txt

I have attached a review package for this bug, hopefully, in time for 10.1.2 release. 

The files affected by this change are
M      java\engine\org\apache\derby\impl\sql\GenericStatement.java
M      java\engine\org\apache\derby\impl\sql\compile\FromList.java
M      java\engine\org\apache\derby\impl\sql\GenericPreparedStatement.java
M      java\testing\org\apache\derbyTesting\functionTests\tests\lang\declareGlobalTempTableJava.java
M      java\testing\org\apache\derbyTesting\functionTests\master\declareGlobalTempTableJava.out

The changes for this fix are very localized, affecting only 3 files in Derby engine. Basically,
the problem is that, during the compile phase of views, the reference to the view gets replaced
by the view definition, which causes us to loose the information that the view might have
belonged in SESSION schema. In order to fix this, during the bind phase in FromList, before
the view gets replaced by its definition, I find out if the view is from SESSION schema, If
yes, then I save this information in FromList and this gets used by FromList when it is asked
if it has any items referencing SESSION schema objects. This information is again lost during
the optimization and generate phase and hence I moved the check for SESSION schema reference
to right after the bind phase in GenericStatement. If there is a reference to SESSION schema
object, GenericStatement will remove the statement from the cache. 

I have put in quite a big of comments in the code which hopefully will make the patch easier
to understand. I have added a new test for this and have run all the tests with no failures
using Sun's jdk142 on Windows XP machine.



> Queryplan for a query using SESSION schema view is incorrectly put in statement cache.
This could cause incorrect plan getting executed later if a temp. table is created with that
name.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-424
>          URL: http://issues.apache.org/jira/browse/DERBY-424
>      Project: Derby
>         Type: Bug
>   Components: SQL
>     Versions: 10.1.1.0, 10.2.0.0
>  Environment: generic
>     Reporter: Satheesh Bandaram
>     Assignee: Mamta A. Satoor
>     Priority: Minor
>  Attachments: Derby424SessionSchemaCaching.txt
>
> See DERBY-405 for some discussion related this issue. I suspect this is because of statement
caching. Derby doesn't seem to recognise we have a temporary table that just overloaded an
existing physical table. 
> It would have been good to avoid permanent tables/views/synonyms in SESSION schema. Not
sure what we should do now about this, though. 
> ij> create view session.st1 as select * from t; 
> 0 rows inserted/updated/deleted 
> ij> select * from session.st1; 
> I |J |K 
> ----------------------------------- 
> 1 |1 |NULL 
> 2 |2 |NULL 
> 3 |3 |NULL 
> 4 |4 |NULL 
> 4 rows selected 
> ij> select * from t; 
> I |J |K 
> ----------------------------------- 
> 1 |1 |NULL 
> 2 |2 |NULL 
> 3 |3 |NULL 
> 4 |4 |NULL 
> 4 rows selected 
> ij> declare global temporary table st1(c11 int, c12 int) on commit preserve rows 
>  not logged; 
> 0 rows inserted/updated/deleted 
> ij> select * from session.st1; 
> I |J |K 
> ----------------------------------- 
> 1 |1 |NULL 
> 2 |2 |NULL 
> 3 |3 |NULL 
> 4 |4 |NULL 
> 4 rows selected 
> ij> select * from session.st1; <==== This statement has an extra space between
FROM and session.st1 
> C11 |C12 
> ----------------------- 
> 0 rows selected 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message