db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5567) AlterTableTest#testDropColumn fails: drop view cannot be performed due to dependency
Date Thu, 26 Jan 2012 21:17:40 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194187#comment-13194187
] 

Dag H. Wanvik commented on DERBY-5567:
--------------------------------------

I was questioning whether this test case is actually correct, although I think it is. In our
doc for DROP VIEW we state the following:

"Any statements referencing the view are invalidated on a DROP VIEW statement. DROP VIEW is
disallowed if there are any views or open cursors dependent on the view. The view must be
dropped before any objects that it is dependent on can be dropped."

The last sentence is pertinent: It states that a view must be dropped *before* any object
it is dependent on can be dropped. In this case the view is clearly dependent on the column
being dropped. This run contrary to the CASCADE semantics for DROP COLUMN.  We also state:
"DROP VIEW is disallowed if there are any views or open cursors dependent on the view."

Probably the intension is that the CASCADE should win here: The statement "The view must be
dropped before any objects that it is dependent on can be dropped." should be qualified with
something like "unless as a result of a drop with CASCADE".

If so, the code that performs view drop here should carry the invalidation action DROP_COLUMN
all the way, not switch to DROP_VIEW. I'll try to make a fix doing that and see how it works
out.

If invalidation of view 2 proceeds indirectly, we have what is seen in
the stack dump I posted:

  drop column
  invalidateFor(DROP_COLUMN): find deps on table and iterate, we find view 1 first
  drop view 1
  invalidateFor(DROP_VIEW)
  check is dependents? yes, view 2 => error

Mostly we see this call order, which works:

  drop column
  invalidateFor(DROP_COLUMN): find deps on table and iterate, we find view 2 first
  drop view 2
  invalidateFor(DROP_VIEW)
  check is dependents? no
  drop view 1
  invalidateFor(DROP_VIEW)
  check is dependents? no
  OK

I think we need to keep the action DROP_COLUMN when we recurse here: dropping view 1 here
is not a result of a DROP VIEW, which would be illegal, but a result of the DROP COLUMN CASCADE,
which should be legal.



                
> AlterTableTest#testDropColumn fails: drop view cannot be performed due to dependency
> ------------------------------------------------------------------------------------
>
>                 Key: DERBY-5567
>                 URL: https://issues.apache.org/jira/browse/DERBY-5567
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.8.2.2
>         Environment: Windows 7 Enterprise SP1, Java 1.7u4 prerelease, -d64
>            Reporter: Dag H. Wanvik
>         Attachments: AlterTableTest.java
>
>
> Saw this when running suitesAll on 10.8.2.2:
> 1) testDropColumn(org.apache.derbyTesting.functionTests.tests.lang.AlterTableTest)java.sql.SQLException:
Operation 'DROP VIEW' cannot be performed on object 'ATDC_VW_5A_1' because VIEW 'ATDC_VW_5A_2'
is dependent on that object.
> 	at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
> 	at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> 	at org.apache.derby.client.am.Statement.executeUpdate(Unknown Source)
> 	at org.apache.derbyTesting.functionTests.tests.lang.AlterTableTest.testDropColumn(AlterTableTest.java:2465)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.apache.derby.client.am.SqlException: Operation 'DROP VIEW' cannot be performed
on object 'ATDC_VW_5A_1' because VIEW 'ATDC_VW_5A_2' is dependent on that object.
> 	at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
> 	at org.apache.derby.client.am.Statement.completeExecuteImmediate(Unknown Source)
> 	at org.apache.derby.client.net.NetStatementReply.parseEXCSQLIMMreply(Unknown Source)
> 	at org.apache.derby.client.net.NetStatementReply.readExecuteImmediate(Unknown Source)
> 	at org.apache.derby.client.net.StatementReply.readExecuteImmediate(Unknown Source)
> 	at org.apache.derby.client.net.NetStatement.readExecuteImmediate_(Unknown Source)
> 	at org.apache.derby.client.am.Statement.readExecuteImmediate(Unknown Source)
> 	at org.apache.derby.client.am.Statement.flowExecute(Unknown Source)
> 	at org.apache.derby.client.am.Statement.executeUpdateX(Unknown Source)
> 	... 55 more
> Prior to this, though, I saw this on the console, but no error/failure. Probably not
related, I believe we have seen this before:
> java.lang.Exception: DRDA_InvalidReplyTooShort.S:Invalid reply from network server: Insufficient
data.
> 	at org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessageWork(Unknown
Source)
> 	at org.apache.derby.impl.drda.NetworkServerControlImpl.consolePropertyMessage(Unknown
Source)
> 	at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source)
> 	at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source)
> 	at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown Source)
> 	at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown Source)
> 	at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source)
> 	at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567)
> 	at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280)
> 	at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:472)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at junit.framework.TestCase.runTest(TestCase.java:164)
> 	at junit.framework.TestCase.runBare(TestCase.java:130)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:120)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:230)
> 	at junit.framework.TestSuite.run(TestSuite.java:225)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:230)
> 	at junit.framework.TestSuite.run(TestSuite.java:225)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:230)
> 	at junit.framework.TestSuite.run(TestSuite.java:225)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:230)
> 	at junit.framework.TestSuite.run(TestSuite.java:225)
> 	at junit.textui.TestRunner.doRun(TestRunner.java:121)
> 	at junit.textui.TestRunner.start(TestRunner.java:185)
> 	at junit.textui.TestRunner.main(TestRunner.java:143)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message