db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yip Ng (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1304) DROP view does not always completely remove view
Date Tue, 19 Sep 2006 19:14:23 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1304?page=all ]

Yip Ng updated DERBY-1304:
--------------------------

    Attachment: derby1304-trunk-stat01.txt
                derby1304-trunk-diff01.txt

Attaching initial patch for DERBY-1304.  

The problem is that DROP VIEW's binding logic is using its superclass QueryTreeNode's bind()
method which just simply returns the object itself.  So there is no actual binding done in
DROP VIEW at all!  It should have created a dependency on the statement, so when its associated
descriptor gets dropped, the statement can be invalidated accordingly.  This explains why
the second DROP VIEW fails since it is not invalidated by the system.  

Another problem I see is if one just prepare the DROP VIEW statement, it will succeed even
if the view does not exist.  This exhibits a different behavior than of DROP TABLE.  I really
think this should stay consistent by throwing error at bind time.  However, doing so will
definitely trigger a lot of diffs to the existing master output files.  Perhaps this behavior
can be corrected in another jira.  Hence in the patch, it only addresses the dependency problem
and let execution handle the view existence checking like before.  derbyall passes with this
patch.    

> DROP view does not always completely remove view
> ------------------------------------------------
>
>                 Key: DERBY-1304
>                 URL: http://issues.apache.org/jira/browse/DERBY-1304
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.1.2.1
>         Environment: Windows XP
>            Reporter: Piet Blok
>         Assigned To: Yip Ng
>             Fix For: 10.2.1.0
>
>         Attachments: derby1304-trunk-diff01.txt, derby1304-trunk-stat01.txt
>
>
> Execute the following scenario:
> Create a schema
> Create a table
> Create a view
> Drop the view
> Drop the table
> Drop the schema
> The first time this sequence executes OK, However, executing the same sequence again
fails on the drop view:
> ERROR X0X05: Table 'view' does not exist.
> When I leave out the create and drop of a view, all goes well, so it seems 
> to have something to do with the view.
> I encountered the problem first using org.apache.derby.jdbc.ClientConnectionPoolDataSource,
but later I found that the problem is reproducable with a simple ij script as follows:
> -- *******************************************************
> -- Setup connection
> -- *******************************************************
> connect 'jdbc:derby://localhost/TestData;create=true;';
> -- *******************************************************
> -- The first time
> -- *******************************************************
> CREATE SCHEMA TEST_SCHEMA;
> CREATE TABLE TEST_SCHEMA.T1 (TABLE_COLUMN LONG VARCHAR);
> CREATE VIEW TEST_SCHEMA.V1 AS SELECT TABLE_COLUMN AS VIEW_COLUMN FROM 
> TEST_SCHEMA.T1;
> DROP VIEW TEST_SCHEMA.V1;
> DROP TABLE TEST_SCHEMA.T1;
> DROP SCHEMA TEST_SCHEMA RESTRICT;
> -- *******************************************************
> -- The second time
> -- *******************************************************
> CREATE SCHEMA TEST_SCHEMA;
> CREATE TABLE TEST_SCHEMA.T1 (TABLE_COLUMN LONG VARCHAR);
> CREATE VIEW TEST_SCHEMA.V1 AS SELECT TABLE_COLUMN AS VIEW_COLUMN FROM 
> TEST_SCHEMA.T1;
> DROP VIEW TEST_SCHEMA.V1; -- This statement fails
> DROP TABLE TEST_SCHEMA.T1;
> DROP SCHEMA TEST_SCHEMA RESTRICT;
> -- *******************************************************
> -- Cleanup
> -- *******************************************************
> disconnect;
> connect 'jdbc:derby://localhost/TestData;shutdown=true;';
> As an explanation why I would like to be able to create and then drop views: I am trying
to interactively create my table setup. When I make mistakes I must drop wrongly defined tables
or views.
> I encountered some other very strange behaviour that might be related to this issue (table
not found when I just created it and wanted to create a second table with a foreign key referencing
the first table), but which I am not yet able to reproduce in a consistent and simple way.

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