Derby
  1. Derby
  2. DERBY-5567

AlterTableTest#testDropColumn fails: drop view cannot be performed due to dependency

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.8.2.2
    • Component/s: SQL
    • Labels:
      None
    • Environment:
      Windows 7 Enterprise SP1, Java 1.7u4 prerelease, -d64
    • Issue & fix info:
      Repro attached
    • Bug behavior facts:
      Regression Test Failure

      Description

      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)

      1. derby-5567-1.diff
        4 kB
        Dag H. Wanvik
      2. AlterTableTest.java
        153 kB
        Dag H. Wanvik

        Issue Links

          Activity

          Hide
          Mamta A. Satoor added a comment -

          Finished backporting upto 10.5 codeline

          Show
          Mamta A. Satoor added a comment - Finished backporting upto 10.5 codeline
          Hide
          Mamta A. Satoor added a comment -

          Backported to 10.5 branch as svn 1396197

          Show
          Mamta A. Satoor added a comment - Backported to 10.5 branch as svn 1396197
          Hide
          Mamta A. Satoor added a comment -

          Backported to 10.6 branch as svn 1396083.

          Show
          Mamta A. Satoor added a comment - Backported to 10.6 branch as svn 1396083.
          Hide
          Mamta A. Satoor added a comment -

          Backported to 10.7 branch as svn 1395854.

          Show
          Mamta A. Satoor added a comment - Backported to 10.7 branch as svn 1395854.
          Hide
          Mamta A. Satoor added a comment -

          I can work on backporting this.

          Show
          Mamta A. Satoor added a comment - I can work on backporting this.
          Hide
          Myrna van Lunteren added a comment -

          Indeed this exists further back, looks like it happened on 10.6 with weme6.2:
          http://people.apache.org/~myrnavl/derby_test_results/v10_6/windows/testlog/weme6.2/1394343-suites.All_diff.txt

          So at some point, this could get backported further.

          Show
          Myrna van Lunteren added a comment - Indeed this exists further back, looks like it happened on 10.6 with weme6.2: http://people.apache.org/~myrnavl/derby_test_results/v10_6/windows/testlog/weme6.2/1394343-suites.All_diff.txt So at some point, this could get backported further.
          Hide
          Dag H. Wanvik added a comment -

          Backported to 10.8 branch as svn 1240258.

          Show
          Dag H. Wanvik added a comment - Backported to 10.8 branch as svn 1240258.
          Hide
          Dag H. Wanvik added a comment -

          Thanks for looking at the patch, Rick. I'll backport this to 10.8 branch, then close it. It can likely be backported further if anyone is interested, the error goes further back.

          Show
          Dag H. Wanvik added a comment - Thanks for looking at the patch, Rick. I'll backport this to 10.8 branch, then close it. It can likely be backported further if anyone is interested, the error goes further back.
          Hide
          Dag H. Wanvik added a comment -

          Committed patch (added javadocs) as svn 1239898.

          Show
          Dag H. Wanvik added a comment - Committed patch (added javadocs) as svn 1239898.
          Hide
          Rick Hillegas added a comment -

          Hi Dag,

          Your reasoning sounds good to me and it looks like the patch does what you described in the comment on 2012-01-27. +1.

          Show
          Rick Hillegas added a comment - Hi Dag, Your reasoning sounds good to me and it looks like the patch does what you described in the comment on 2012-01-27. +1.
          Hide
          Dag H. Wanvik added a comment - - edited

          For the record, the reason the dependencies are sometimes accessed in a different order is the fact they are held in a hash table keyed by their UUID, cf.
          ProviderList.addProvider. Although the dependencies are always added in the same order in the bind phase, when they are retrieved, they may come back in a different order, cf BasicDependencyManager.getPersistentProvideInfos which retrieves an Enumeration from the hash table.

          Show
          Dag H. Wanvik added a comment - - edited For the record, the reason the dependencies are sometimes accessed in a different order is the fact they are held in a hash table keyed by their UUID, cf. ProviderList.addProvider. Although the dependencies are always added in the same order in the bind phase, when they are retrieved, they may come back in a different order, cf BasicDependencyManager.getPersistentProvideInfos which retrieves an Enumeration from the hash table.
          Hide
          Dag H. Wanvik added a comment -

          Regressions passed with the patch.

          Show
          Dag H. Wanvik added a comment - Regressions passed with the patch.
          Hide
          Dag H. Wanvik added a comment -

          As for tests, the only way I know to provoke this error frequently is by running AlterTableTest with a fixed ordering, cf the attachment. We probably do not want to commit that change, so the patch only includes the change to ViewDescriptor. For test driving the patch, I would suggest using the attached test since that is likely to pop the error.

          Show
          Dag H. Wanvik added a comment - As for tests, the only way I know to provoke this error frequently is by running AlterTableTest with a fixed ordering, cf the attachment. We probably do not want to commit that change, so the patch only includes the change to ViewDescriptor. For test driving the patch, I would suggest using the attached test since that is likely to pop the error.
          Hide
          Dag H. Wanvik added a comment -

          Uploading a patch derby-5567-1, which implements the strategy described above. In addition to retaining the original invalidation action when recursing through views to their dependents, I added a check in ViewDescriptor#makeInvalid to see if the data dictionary entry is already gone lest we try to remove it twice. An absence of this test would lead to a NPE in the case under consideration (td would be null).

          In addition to dropping columns, revoking privileges or dropping roles will also lead to dependent views being dropped in the current implementation. The bug seen may or may not occur in that case, but the patch makes the code retain those invalidation actions also, when recursing invalidation through a view's dependents.

          Running regressions.

          Show
          Dag H. Wanvik added a comment - Uploading a patch derby-5567-1, which implements the strategy described above. In addition to retaining the original invalidation action when recursing through views to their dependents, I added a check in ViewDescriptor#makeInvalid to see if the data dictionary entry is already gone lest we try to remove it twice. An absence of this test would lead to a NPE in the case under consideration (td would be null). In addition to dropping columns, revoking privileges or dropping roles will also lead to dependent views being dropped in the current implementation. The bug seen may or may not occur in that case, but the patch makes the code retain those invalidation actions also, when recursing invalidation through a view's dependents. Running regressions.
          Hide
          Dag H. Wanvik added a comment -

          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.

          Show
          Dag H. Wanvik added a comment - 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.
          Hide
          Dag H. Wanvik added a comment -

          Looking at the dependencies being recorded it looks like when the error occur in the client suite, the dependencies are registered in a slightly different order than when it succeeds for the table/two views in question:

          This order seems to always (as traced from CreateViewConstantAction#executeConstantAction: dm.addDependency);

          TDC_VW_5A_1 depends on t ATDC_5A
          ATDC_VW_5A_2 depends on t ATDC_5A
          ATDC_VW_5A_2 depends on v ATDC_VW_5A_1

          Sometimes however, the depdendencies are registered in this order (no
          idea why yet):

          ATDC_VW_5A_1 depends on t ATDC_5A
          ATDC_VW_5A_2 depends on v ATDC_VW_5A_1
          ATDC_VW_5A_2 depends on t ATDC_5A

          If this happens for the client of the test, the drop column will give
          the seen error.

          A possible theory is that when invalidating from dropping the column
          "b", the direct dependency "ATDC_VW_5A_2 depends on t ATDC_5A" is
          inspected first and the view ATDC_VW_5A_2 is dropped because the action
          DROP_COLUMN allows this (CASCADE).

          If, however, the invalidation first picks up the indirect depedency
          transitively (as seems to happen in the stack trace, cf the two levels
          of invalidateFor), i.e. it inspects the direct dependency
          "ATDC_VW_5A_1 depends on t ATDC_5A" first:

          ATDC_VW_5A_1 depends on t ATDC_5A -> leads to
          ATDC_VW_5A_2 depends on v ATDC_VW_5A_1

          and the last action is DROP_VIEW when one hits the dependent
          ATDC_VW_5A_2 (from ATDC_VW_5A_1), cf.
          ViewDescripotor#prepareToInvalidate cease "default" which throws an
          error as seen.

          Presumaby, if the invalidation first inspects "ATDC_VW_5A_2 depends on
          t ATDC_5A", the indirect depdency will be removed (since ATDC_VW_5A_2
          is now gone) before it is inspected and the action DROP_VIEW is used.

          Show
          Dag H. Wanvik added a comment - Looking at the dependencies being recorded it looks like when the error occur in the client suite, the dependencies are registered in a slightly different order than when it succeeds for the table/two views in question: This order seems to always (as traced from CreateViewConstantAction#executeConstantAction: dm.addDependency); TDC_VW_5A_1 depends on t ATDC_5A ATDC_VW_5A_2 depends on t ATDC_5A ATDC_VW_5A_2 depends on v ATDC_VW_5A_1 Sometimes however, the depdendencies are registered in this order (no idea why yet): ATDC_VW_5A_1 depends on t ATDC_5A ATDC_VW_5A_2 depends on v ATDC_VW_5A_1 ATDC_VW_5A_2 depends on t ATDC_5A If this happens for the client of the test, the drop column will give the seen error. A possible theory is that when invalidating from dropping the column "b", the direct dependency "ATDC_VW_5A_2 depends on t ATDC_5A" is inspected first and the view ATDC_VW_5A_2 is dropped because the action DROP_COLUMN allows this (CASCADE). If, however, the invalidation first picks up the indirect depedency transitively (as seems to happen in the stack trace, cf the two levels of invalidateFor), i.e. it inspects the direct dependency "ATDC_VW_5A_1 depends on t ATDC_5A" first: ATDC_VW_5A_1 depends on t ATDC_5A -> leads to ATDC_VW_5A_2 depends on v ATDC_VW_5A_1 and the last action is DROP_VIEW when one hits the dependent ATDC_VW_5A_2 (from ATDC_VW_5A_1), cf. ViewDescripotor#prepareToInvalidate cease "default" which throws an error as seen. Presumaby, if the invalidation first inspects "ATDC_VW_5A_2 depends on t ATDC_5A", the indirect depdency will be removed (since ATDC_VW_5A_2 is now gone) before it is inspected and the action DROP_VIEW is used.
          Hide
          Dag H. Wanvik added a comment -

          The stack trace on the server side (from derby.log) looks like this (trunk):

          ERROR X0Y23: 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.iapi.error.StandardException.newException(StandardException.java:335)
          at org.apache.derby.iapi.sql.dictionary.ViewDescriptor.prepareToInvalidate(ViewDescriptor.java:308)
          at org.apache.derby.impl.sql.depend.BasicDependencyManager.coreInvalidateFor(BasicDependencyManager.java:437)
          at org.apache.derby.impl.sql.depend.BasicDependencyManager.invalidateFor(BasicDependencyManager.java:298)
          at org.apache.derby.iapi.sql.dictionary.ViewDescriptor.drop(ViewDescriptor.java:428)
          at org.apache.derby.iapi.sql.dictionary.ViewDescriptor.makeInvalid(ViewDescriptor.java:365)
          at org.apache.derby.impl.sql.depend.BasicDependencyManager.coreInvalidateFor(BasicDependencyManager.java:460)
          at org.apache.derby.impl.sql.depend.BasicDependencyManager.invalidateFor(BasicDependencyManager.java:298)
          at org.apache.derby.impl.sql.execute.AlterTableConstantAction.dropColumnFromTable(AlterTableConstantAction.java:1362)
          at org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantActionBody(AlterTableConstantAction.java:507)
          at org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(AlterTableConstantAction.java:276)
          at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:61)
          at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:443)
          at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:324)
          at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
          at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:630)
          at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179)
          at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:5215)
          at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:779)
          at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295)
          Cleanup action completed

          Show
          Dag H. Wanvik added a comment - The stack trace on the server side (from derby.log) looks like this (trunk): ERROR X0Y23: 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.iapi.error.StandardException.newException(StandardException.java:335) at org.apache.derby.iapi.sql.dictionary.ViewDescriptor.prepareToInvalidate(ViewDescriptor.java:308) at org.apache.derby.impl.sql.depend.BasicDependencyManager.coreInvalidateFor(BasicDependencyManager.java:437) at org.apache.derby.impl.sql.depend.BasicDependencyManager.invalidateFor(BasicDependencyManager.java:298) at org.apache.derby.iapi.sql.dictionary.ViewDescriptor.drop(ViewDescriptor.java:428) at org.apache.derby.iapi.sql.dictionary.ViewDescriptor.makeInvalid(ViewDescriptor.java:365) at org.apache.derby.impl.sql.depend.BasicDependencyManager.coreInvalidateFor(BasicDependencyManager.java:460) at org.apache.derby.impl.sql.depend.BasicDependencyManager.invalidateFor(BasicDependencyManager.java:298) at org.apache.derby.impl.sql.execute.AlterTableConstantAction.dropColumnFromTable(AlterTableConstantAction.java:1362) at org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantActionBody(AlterTableConstantAction.java:507) at org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(AlterTableConstantAction.java:276) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:61) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:443) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:324) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:630) at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:179) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:5215) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:779) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) Cleanup action completed
          Hide
          Dag H. Wanvik added a comment -

          Another data point: In all cases, it is the client version of the test fixture that fails.

          Show
          Dag H. Wanvik added a comment - Another data point: In all cases, it is the client version of the test fixture that fails.
          Hide
          Dag H. Wanvik added a comment -

          Using the fixed ordering, I am also able to reproduce on the trunk, not just 10.8 head.

          Show
          Dag H. Wanvik added a comment - Using the fixed ordering, I am also able to reproduce on the trunk, not just 10.8 head.
          Hide
          Dag H. Wanvik added a comment - - edited

          Apprently this error happens due to a special fixture ordering in the new VM. I observed similar fixture ordering in the runs that saw the error. I enclose a version of AlterTableTest which uses fixed deterministic fixture ordering, using the observed ordering in the erroneous runs. This reproduces the error on my Solaris box fairly easily, although not on every run (about 50-70% of runs).

          Show
          Dag H. Wanvik added a comment - - edited Apprently this error happens due to a special fixture ordering in the new VM. I observed similar fixture ordering in the runs that saw the error. I enclose a version of AlterTableTest which uses fixed deterministic fixture ordering, using the observed ordering in the erroneous runs. This reproduces the error on my Solaris box fairly easily, although not on every run (about 50-70% of runs).
          Hide
          Dag H. Wanvik added a comment -

          By running suitesAll but removing suites after lang I can reproduce this more often on 10.8 (sane trunk this time), 16 out of 47 runs.

          Show
          Dag H. Wanvik added a comment - By running suitesAll but removing suites after lang I can reproduce this more often on 10.8 (sane trunk this time), 16 out of 47 runs.
          Hide
          Dag H. Wanvik added a comment -

          I was able to repeat this on my 64 bits Windows (in a VM) again, running full suitesAll, at attempt #14, so not easy to reproduce.
          I tried just running the lang suite but that didn't pop it yet.

          Show
          Dag H. Wanvik added a comment - I was able to repeat this on my 64 bits Windows (in a VM) again, running full suitesAll, at attempt #14, so not easy to reproduce. I tried just running the lang suite but that didn't pop it yet.
          Hide
          Dag H. Wanvik added a comment -

          Not standalone anyway (tried 5 iterations).

          Show
          Dag H. Wanvik added a comment - Not standalone anyway (tried 5 iterations).
          Hide
          Knut Anders Hatlen added a comment -

          Here's the sequence of statements that fails (line numbers have changed from 10.8.2.2 to trunk). It's the last statement (alter table ... drop column) that fails.

          // cascade processing should transitively drop a view
          // dependent on a view dependent in turn on the column
          // being dropped:

          st.executeUpdate("create table atdc_5a (a int, b int, c int)");

          st.executeUpdate(
          " create view atdc_vw_5a_1 (vw_5a_b, vw_5a_c) as " +
          "select b,c from atdc_5a");

          st.executeUpdate(
          " create view atdc_vw_5a_2 (vw_5a_c_2) as select " +
          "vw_5a_c from atdc_vw_5a_1");

          st.executeUpdate("alter table atdc_5a drop column b cascade");

          This looks like a fairly straightforward and independent piece of code. Since the table and the views were created successfully just before the ALTER TABLE statement, and there are no dependencies on other tables, I don't see how this failure could be caused by a problem in the test itself. It feels like a real bug.

          I don't suppose it's reproducible?

          Show
          Knut Anders Hatlen added a comment - Here's the sequence of statements that fails (line numbers have changed from 10.8.2.2 to trunk). It's the last statement (alter table ... drop column) that fails. // cascade processing should transitively drop a view // dependent on a view dependent in turn on the column // being dropped: st.executeUpdate("create table atdc_5a (a int, b int, c int)"); st.executeUpdate( " create view atdc_vw_5a_1 (vw_5a_b, vw_5a_c) as " + "select b,c from atdc_5a"); st.executeUpdate( " create view atdc_vw_5a_2 (vw_5a_c_2) as select " + "vw_5a_c from atdc_vw_5a_1"); st.executeUpdate("alter table atdc_5a drop column b cascade"); This looks like a fairly straightforward and independent piece of code. Since the table and the views were created successfully just before the ALTER TABLE statement, and there are no dependencies on other tables, I don't see how this failure could be caused by a problem in the test itself. It feels like a real bug. I don't suppose it's reproducible?

            People

            • Assignee:
              Dag H. Wanvik
              Reporter:
              Dag H. Wanvik
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development