Derby
  1. Derby
  2. DERBY-5977

Run storemore and possibly other store .sql tests in junit harness using ScriptTest mechanism.

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.10.1.1
    • Component/s: Test
    • Labels:
      None

      Description

      There are a number of .sql tests in the storemore suite, which might be able to in the junit framework through a scriptTest.
      They can still be fully converted at a later stage if we need more control.

      1. DERBY-5977_3.diff
        72 kB
        Myrna van Lunteren
      2. DERBY-5977_3.stat
        1 kB
        Myrna van Lunteren
      3. DERBY-5977_3.diff
        25 kB
        Myrna van Lunteren
      4. DERBY-5977_3.stat
        0.5 kB
        Myrna van Lunteren
      5. DERBY-5977_2.diff
        2.00 MB
        Myrna van Lunteren
      6. DERBY-5977_2.stat
        4 kB
        Myrna van Lunteren
      7. DERBY-5977_1.diff
        2.69 MB
        Myrna van Lunteren
      8. DERBY-5977_1.stat
        4 kB
        Myrna van Lunteren

        Issue Links

          Activity

          Hide
          Myrna van Lunteren added a comment -

          Attaching a patch that shows what .sql files I think can be run through the junit scriptest mechanism and what changes need to be made to the .sql files and masters to accomodate this.

          This is a massive patch, because of white space diffs and other minor changes in the .sql scripts and masters, but the more interesting change is the new test StoreScriptsTest.java.
          There is also a new StoreHarnessJavaTest.java, which maybe can run (some of) the old java tests, but I've not worked on that one yet.

          The main issue I have with the new StoreScriptsTest.java is that I could not get the scripts to work correctly unless I modified every "connect 'wombat'" statement to "connect 'jdbc:derby;wombat".
          This however does force a call to DriverManager, making it impossible for these tests to run under (current) J2ME platforms which only have DataSource available.
          I thought this would be unnecessary if I set the properties for ij.protocol, but it didn't work.

          Does anyone know how to address this?

          Show
          Myrna van Lunteren added a comment - Attaching a patch that shows what .sql files I think can be run through the junit scriptest mechanism and what changes need to be made to the .sql files and masters to accomodate this. This is a massive patch, because of white space diffs and other minor changes in the .sql scripts and masters, but the more interesting change is the new test StoreScriptsTest.java. There is also a new StoreHarnessJavaTest.java, which maybe can run (some of) the old java tests, but I've not worked on that one yet. The main issue I have with the new StoreScriptsTest.java is that I could not get the scripts to work correctly unless I modified every "connect 'wombat'" statement to "connect 'jdbc:derby;wombat". This however does force a call to DriverManager, making it impossible for these tests to run under (current) J2ME platforms which only have DataSource available. I thought this would be unnecessary if I set the properties for ij.protocol, but it didn't work. Does anyone know how to address this?
          Hide
          Myrna van Lunteren added a comment -

          patch ready for review

          Show
          Myrna van Lunteren added a comment - patch ready for review
          Hide
          Mamta A. Satoor added a comment -

          Hi Myrna, thanks for working on this issue. I looked at the part of the patch where you are setting "ij.protocol" to "jdbc:derby:". But for J2ME platforms, you probably need to set "ij.dataSource" property. I think including the relevant ij properties for J2ME should take care of connect "wombat" without having to change them to connect 'jdbc:derby;wombat'.

          Show
          Mamta A. Satoor added a comment - Hi Myrna, thanks for working on this issue. I looked at the part of the patch where you are setting "ij.protocol" to "jdbc:derby:". But for J2ME platforms, you probably need to set "ij.dataSource" property. I think including the relevant ij properties for J2ME should take care of connect "wombat" without having to change them to connect 'jdbc:derby;wombat'.
          Hide
          Myrna van Lunteren added a comment -

          Attaching a patch which I think is viable for commit.

          I resolved the dataSource/connect issues a long time ago, by fiddling with the SystemPropertyTestSetup.

          The patch is pretty big because of resulting IMO acceptable changes to the .out files:

          • As a result of running the sql scripts through the junit ScriptTest mechanism, there seems to be an extra connection, so that the changes to the .out files are substantial in some cases (because every 'ij>' now turns into ij>(CONNECTION1').
          • run resource - I had to fully qualify the (sub)sql file names.
          • there were extra blank lines in the output that I think the old test harness was filtering away.

          Finally I was left with a failure only when running suites.All. I would see a number of XSCB6 error in store.AccessTest as run in the EncryptionSuite. (running AccessTest directly after StoreScriptTest in store._Suite did not result in such a failure). After narrowing down, I found it was caused by running databaseProperties.sql first.
          Adding a rollback to databaseProperties.sql changed the number of test failures in AccessTest in EncryptionSuite. Setting derby.storage.pageSize to NULL in the teardown method of StoreScriptTest did not change that; adding a call to set it to NULL in the .sql file only increased the number of failing test cases in AccessTest (in EncryptionSuite).
          So once I identified which sql file caused the problem, I commented out databaseProperties from the StoreScriptsTest, and now suites.All runs cleanly in my environment (I tested with ibm 1.6 and weme6.2). I intend to look into this further after commit.

          (XSBC6 error: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation)

          Show
          Myrna van Lunteren added a comment - Attaching a patch which I think is viable for commit. I resolved the dataSource/connect issues a long time ago, by fiddling with the SystemPropertyTestSetup. The patch is pretty big because of resulting IMO acceptable changes to the .out files: As a result of running the sql scripts through the junit ScriptTest mechanism, there seems to be an extra connection, so that the changes to the .out files are substantial in some cases (because every 'ij>' now turns into ij>(CONNECTION1'). run resource - I had to fully qualify the (sub)sql file names. there were extra blank lines in the output that I think the old test harness was filtering away. Finally I was left with a failure only when running suites.All. I would see a number of XSCB6 error in store.AccessTest as run in the EncryptionSuite. (running AccessTest directly after StoreScriptTest in store._Suite did not result in such a failure). After narrowing down, I found it was caused by running databaseProperties.sql first. Adding a rollback to databaseProperties.sql changed the number of test failures in AccessTest in EncryptionSuite. Setting derby.storage.pageSize to NULL in the teardown method of StoreScriptTest did not change that; adding a call to set it to NULL in the .sql file only increased the number of failing test cases in AccessTest (in EncryptionSuite). So once I identified which sql file caused the problem, I commented out databaseProperties from the StoreScriptsTest, and now suites.All runs cleanly in my environment (I tested with ibm 1.6 and weme6.2). I intend to look into this further after commit. (XSBC6 error: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation)
          Hide
          Mike Matrigali added a comment -

          at one point in the databaseProperties test it sets that SYSTEM pageSize. This is likely causing at least some of the problems. Best would be to change the
          test to unset the system property after it does the test it is trying to do. I don't see an existing utility, so may need to add one.

          Do you know in the new environment if the test is run with autocommit on or off? I would suggest running the test with autocommit off and then run an abort at the end
          of the script.

          Here is a web hit on how to delete
          a system property:

          8/30/2006
          How to Remove a System Property

          I thought I could remove a system property by setting its value to null, but it turns out that System.setProperty(key, val) will throw NullPointerException when either key or value is null. Here are 2 ways to remove or clear a system property:

          1. clearProperty(String key) introduced in JDK 1.5.

          System.clearProperty("key");

          2.

          Properties sysProps = System.getProperties();
          sysProps.remove("key");
          When java security manager is enabled, Both methods need specific permissions to succeed. Approach 1 requires PropertyPermission "key", "read,write". Approach 2 requires a much wider permission: PropertyPermission "*", "read,write", because you are free to modify/remove all system properties with the returned object from System.getProperties()

          Show
          Mike Matrigali added a comment - at one point in the databaseProperties test it sets that SYSTEM pageSize. This is likely causing at least some of the problems. Best would be to change the test to unset the system property after it does the test it is trying to do. I don't see an existing utility, so may need to add one. Do you know in the new environment if the test is run with autocommit on or off? I would suggest running the test with autocommit off and then run an abort at the end of the script. Here is a web hit on how to delete a system property: 8/30/2006 How to Remove a System Property I thought I could remove a system property by setting its value to null, but it turns out that System.setProperty(key, val) will throw NullPointerException when either key or value is null. Here are 2 ways to remove or clear a system property: 1. clearProperty(String key) introduced in JDK 1.5. System.clearProperty("key"); 2. Properties sysProps = System.getProperties(); sysProps.remove("key"); When java security manager is enabled, Both methods need specific permissions to succeed. Approach 1 requires PropertyPermission "key", "read,write". Approach 2 requires a much wider permission: PropertyPermission "*", "read,write", because you are free to modify/remove all system properties with the returned object from System.getProperties()
          Hide
          Mike Matrigali added a comment -

          can you ever tell what test/line the error is coming on. It would be good to understand if the test is expecting a btree with a large page size so that it can do inserts, but for some reason
          either system property or database property the index has a smaller page size. That is the usual case and not a bug in the code.

          Show
          Mike Matrigali added a comment - can you ever tell what test/line the error is coming on. It would be good to understand if the test is expecting a btree with a large page size so that it can do inserts, but for some reason either system property or database property the index has a smaller page size. That is the usual case and not a bug in the code.
          Hide
          Myrna van Lunteren added a comment -

          I committed patch DERBY-5977_2 to trunk with revision 1443812 (http://svn.apache.org/viewvc?view=revision&revision=1443812).

          I'll next look at enabling databaseProperties.sql in the new StoreScriptsTest.

          Show
          Myrna van Lunteren added a comment - I committed patch DERBY-5977 _2 to trunk with revision 1443812 ( http://svn.apache.org/viewvc?view=revision&revision=1443812 ). I'll next look at enabling databaseProperties.sql in the new StoreScriptsTest.
          Hide
          Myrna van Lunteren added a comment - - edited

          Attaching a patch that adds databaseProperties.sql to the list of scripts run in StoreScriptsTest.
          The teardown method now removes the system property set in databaseProperties.sql (derby.storage.pageSize), which was affecting the AccessTest. There was a method already present in BaseTestCase for this.

          I also added 2 test cases to databaseProperties.sql, to confirm that setting the property to an invalid value does indeed revert back to the default. In one test case the invalid value is 'a', in the other, 'NULL'.

          This patch makes a modified suites.All (with just the EncryptionSuite following StoreScriptsTest) pass.

          I intend to commit this if the full suite passes.

          Show
          Myrna van Lunteren added a comment - - edited Attaching a patch that adds databaseProperties.sql to the list of scripts run in StoreScriptsTest. The teardown method now removes the system property set in databaseProperties.sql (derby.storage.pageSize), which was affecting the AccessTest. There was a method already present in BaseTestCase for this. I also added 2 test cases to databaseProperties.sql, to confirm that setting the property to an invalid value does indeed revert back to the default. In one test case the invalid value is 'a', in the other, 'NULL'. This patch makes a modified suites.All (with just the EncryptionSuite following StoreScriptsTest) pass. I intend to commit this if the full suite passes.
          Hide
          Myrna van Lunteren added a comment -

          For completeness' sake, the AccessTest fixture that failed before, was testLoadLongColumnsCreateIndex (and in some cases, after attempted rollback, a subsequent fixture expected the same error, but did not get it).
          Here's a snippet from a stack trace:
          java.sql.SQLException: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation.
          at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98)
          at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)
          at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424)
          at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
          at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400)
          at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
          at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334)
          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.derbyTesting.functionTests.tests.store.AccessTest.testLoadLongColumnsCreateIndex(AccessTest.java:822)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
          at java.lang.reflect.Method.invoke(Method.java:611)
          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:117)
          at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
          at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
          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.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.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 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.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)
          Caused by: java.sql.SQLException: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation.
          at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
          at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
          at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
          ... 48 more
          Caused by: ERROR XSCB6: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation.
          at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:268)
          at org.apache.derby.impl.store.access.btree.BTreeController.doIns(BTreeController.java:958)
          at org.apache.derby.impl.store.access.btree.BTreeController.insert(BTreeController.java:1373)
          at org.apache.derby.impl.store.access.btree.index.B2IController.insert(B2IController.java:210)
          at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(IndexChanger.java:440)
          at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(IndexChanger.java:383)
          at org.apache.derby.impl.sql.execute.IndexChanger.insert(IndexChanger.java:590)
          at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(IndexSetChanger.java:268)
          at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java:453)
          at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1058)
          at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:518)
          at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:452)
          at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:333)
          at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242)
          ... 42 more

          But as Mike said, this seems logical considering the system property was still set.

          Show
          Myrna van Lunteren added a comment - For completeness' sake, the AccessTest fixture that failed before, was testLoadLongColumnsCreateIndex (and in some cases, after attempted rollback, a subsequent fixture expected the same error, but did not get it). Here's a snippet from a stack trace: java.sql.SQLException: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2400) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1334) 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.derbyTesting.functionTests.tests.store.AccessTest.testLoadLongColumnsCreateIndex(AccessTest.java:822) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) 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:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441) 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.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.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 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.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) Caused by: java.sql.SQLException: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) ... 48 more Caused by: ERROR XSCB6: Limitation: Record of a btree secondary index cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:268) at org.apache.derby.impl.store.access.btree.BTreeController.doIns(BTreeController.java:958) at org.apache.derby.impl.store.access.btree.BTreeController.insert(BTreeController.java:1373) at org.apache.derby.impl.store.access.btree.index.B2IController.insert(B2IController.java:210) at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(IndexChanger.java:440) at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(IndexChanger.java:383) at org.apache.derby.impl.sql.execute.IndexChanger.insert(IndexChanger.java:590) at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(IndexSetChanger.java:268) at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java:453) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1058) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:518) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:452) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:333) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1242) ... 42 more But as Mike said, this seems logical considering the system property was still set.
          Hide
          Myrna van Lunteren added a comment -

          committed patch 3 with revision 1446227 (http://svn.apache.org/viewvc?view=revision&revision=1446227)

          Show
          Myrna van Lunteren added a comment - committed patch 3 with revision 1446227 ( http://svn.apache.org/viewvc?view=revision&revision=1446227 )
          Hide
          Myrna van Lunteren added a comment - - edited

          I tried to make a StoreHarnessJavaTest, similar to LangHarnessJavaTest, with the .java tests from the storemore suite.
          However, only 1 test of this passed (OnlineCompressTest), the others failed with security permissions. So I don't think it's worth while adding such a wrapper, I think it's better to do the actual conversion to junit for these.

          Show
          Myrna van Lunteren added a comment - - edited I tried to make a StoreHarnessJavaTest, similar to LangHarnessJavaTest, with the .java tests from the storemore suite. However, only 1 test of this passed (OnlineCompressTest), the others failed with security permissions. So I don't think it's worth while adding such a wrapper, I think it's better to do the actual conversion to junit for these.
          Hide
          Myrna van Lunteren added a comment -

          Attaching a patch which moves two .sql scripts from the storetests directory and suite to the StoreScriptsTest, and removes 1 .sql file altogether.

          The storetests are merely a group of store tests that could run after one another while using the same database, there is functionality that sets them apart from other store tests, so there should be no objection to moving them over.

          st_1.sql was the initial test created to ensure calls to the SYSCS_UTIL schema and its procedures can be made, but all the functionality is by now also covered in other tests, so I think it can just be removed.

          If removing st_1.sql is not OK, I can move st_1 to the store directory instead...

          Show
          Myrna van Lunteren added a comment - Attaching a patch which moves two .sql scripts from the storetests directory and suite to the StoreScriptsTest, and removes 1 .sql file altogether. The storetests are merely a group of store tests that could run after one another while using the same database, there is functionality that sets them apart from other store tests, so there should be no objection to moving them over. st_1.sql was the initial test created to ensure calls to the SYSCS_UTIL schema and its procedures can be made, but all the functionality is by now also covered in other tests, so I think it can just be removed. If removing st_1.sql is not OK, I can move st_1 to the store directory instead...
          Hide
          Myrna van Lunteren added a comment - - edited

          forgot to mention; the changes of patch _3 pass derbyall and suites.All with ibm1.6 and weme6.2.

          Show
          Myrna van Lunteren added a comment - - edited forgot to mention; the changes of patch _3 pass derbyall and suites.All with ibm1.6 and weme6.2.
          Hide
          Myrna van Lunteren added a comment -

          I committed patch DERBY-5977_3.diff with revision 1451262 (http://svn.apache.org/viewvc?view=revision&revision=1451262).

          Show
          Myrna van Lunteren added a comment - I committed patch DERBY-5977 _3.diff with revision 1451262 ( http://svn.apache.org/viewvc?view=revision&revision=1451262 ).
          Hide
          Myrna van Lunteren added a comment -

          I don't intend to do any more work on this particular issue.

          Show
          Myrna van Lunteren added a comment - I don't intend to do any more work on this particular issue.

            People

            • Assignee:
              Myrna van Lunteren
              Reporter:
              Myrna van Lunteren
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development