Derby
  1. Derby
  2. DERBY-3801

Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.

    Details

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

      Description

      Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.

      1. DERBY-3801-7.diff
        22 kB
        Myrna van Lunteren
      2. DERBY-3801-7.stat
        0.7 kB
        Myrna van Lunteren
      3. derby-3801-6.stat
        1 kB
        Yun Lee
      4. derby-3801-6.patch
        85 kB
        Yun Lee
      5. derby-3801-5.stat
        0.9 kB
        Yun Lee
      6. derby-3801-5.patch
        65 kB
        Yun Lee
      7. derby-3801-4.patch
        3 kB
        Yun Lee
      8. DERBY-3801-Tiago.patch
        26 kB
        Tiago R. Espinha
      9. derby-3801-2.stat
        0.1 kB
        Junjie Peng
      10. derby-3801-2.patch
        24 kB
        Junjie Peng
      11. derby-3801-1-patch.txt
        7 kB
        Junjie Peng

        Issue Links

          Activity

          Hide
          Junjie Peng added a comment -

          Ask for help!
          The patch derby-3801-1-patch.txt is part of testing case for holdCursorIJ.sql. I have trouble with translating the third test case, whch is from Line 84 to Line 112 in holdCursorIJ.sql. When I run the test case with TestRunner, an exception is thrown, indicating that

          1) testDropTableWithOpenHoldCursor(org.apache.derbyTesting.functionTests.tests.l
          ang.HoldCursorIJTest)junit.framework.ComparisonFailure: Unexpected SQL state. ex
          pected:<42Y5...> but was:<X0X9...>
          at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
          CTestCase.java:760)
          at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
          CTestCase.java:809)
          at org.apache.derbyTesting.junit.BaseJDBCTestCase.dropTable(BaseJDBCTest
          Case.java:941)
          at org.apache.derbyTesting.junit.BaseJDBCTestCase.dropTable(BaseJDBCTest
          Case.java:922)
          at org.apache.derbyTesting.functionTests.tests.lang.HoldCursorIJTest.tes
          tDropTableWithOpenHoldCursor(HoldCursorIJTest.java:228)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
          java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
          sorImpl.java:25)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          104)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
          )

          I don't know why. Because I have expected SQLException X0X95 in Line 228 of org.apache.derbyTesting.functionTests.tests.l
          ang.HoldCursorIJTest.

          Is something wrong with my IJ?
          Thank you!

          Show
          Junjie Peng added a comment - Ask for help! The patch derby-3801-1-patch.txt is part of testing case for holdCursorIJ.sql. I have trouble with translating the third test case, whch is from Line 84 to Line 112 in holdCursorIJ.sql. When I run the test case with TestRunner, an exception is thrown, indicating that 1) testDropTableWithOpenHoldCursor(org.apache.derbyTesting.functionTests.tests.l ang.HoldCursorIJTest)junit.framework.ComparisonFailure: Unexpected SQL state. ex pected:<42Y5...> but was:<X0X9...> at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB CTestCase.java:760) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB CTestCase.java:809) at org.apache.derbyTesting.junit.BaseJDBCTestCase.dropTable(BaseJDBCTest Case.java:941) at org.apache.derbyTesting.junit.BaseJDBCTestCase.dropTable(BaseJDBCTest Case.java:922) at org.apache.derbyTesting.functionTests.tests.lang.HoldCursorIJTest.tes tDropTableWithOpenHoldCursor(HoldCursorIJTest.java:228) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 104) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57 ) I don't know why. Because I have expected SQLException X0X95 in Line 228 of org.apache.derbyTesting.functionTests.tests.l ang.HoldCursorIJTest. Is something wrong with my IJ? Thank you!
          Hide
          Myrna van Lunteren added a comment -

          I looked a little at this, and what you're seeing is actually expected behavior difference between DerbyNetClient and embedded. DerbyNetClient passes; embedded fails. And indeed, if I modify your suite method to do this:
          ...
          return TestConfiguration.clientServerSuite(
          //return TestConfiguration.defaultSuite(
          HoldCursorIJTest.class);
          }
          the test passes. If I use TestConfiguration.embeddedSuite(HoldCursorIJTest.class) we 2 passes, and 1 failure: the error you saw - for the embedded run.

          There are 2 (actually 3, but let's ignore the DerbyNet one for the purpose of this discussion) canons (variations of a master file):

          • ...functionTests/master/HoldCursorIJ.out
          • ...functionTests/master/DerbyNetClient/HoldCursorIJ.out

          If you diff the two original masters you'll see that in the affected area, embedded gives error X0X95 and DerbyNetClient gives 42Y55.
          There are comments in the .sql (and thus in the .out files) that explain some of the difference in behavior; in derbyNetClient, the cursor (on the server) is already closed, and thus, the table gets dropped earlier.
          I wasn't familiar with this difference, so I looked up in the svn browser (starting at the top of trunk: http://svn.apache.org/viewvc/db/derby/) where these comments were added and found this change: http://svn.apache.org/viewvc?view=rev&revision=377367.
          This refers to https://issues.apache.org/jira/browse/DERBY-821, and there we can see Knut Anders' explanation for this difference.

          All that said, I have some misgivings on how you're approaching this conversion.
          There is already a hold-cursor junit test (...functionTests/tests/lang/holdCursorTest, from original holdCursorJava.
          Because there's such a clear reference to IJ I think the purpose of this test was to do some testing of the hold cursor functionality in ij. So, I'd suggest converting this test using the ScriptTest mechanism. Examples of how this can be done are:
          ...functionTests/tests/tools/ijRunScriptTest
          ...functionTests/tests/tools/ToolScripts
          ...functionTests/tests/nist/NistScripts
          ...functionTests/tests/derbynet/NetIjTest
          You'd have to find a way to make a separate comparison between NetworkServer/DerbyNetClient vs. Embedded. Maybe the easiest is to have two tests...

          Myrna

          Show
          Myrna van Lunteren added a comment - I looked a little at this, and what you're seeing is actually expected behavior difference between DerbyNetClient and embedded. DerbyNetClient passes; embedded fails. And indeed, if I modify your suite method to do this: ... return TestConfiguration.clientServerSuite( //return TestConfiguration.defaultSuite( HoldCursorIJTest.class); } the test passes. If I use TestConfiguration.embeddedSuite(HoldCursorIJTest.class) we 2 passes, and 1 failure: the error you saw - for the embedded run. There are 2 (actually 3, but let's ignore the DerbyNet one for the purpose of this discussion) canons (variations of a master file): ...functionTests/master/HoldCursorIJ.out ...functionTests/master/DerbyNetClient/HoldCursorIJ.out If you diff the two original masters you'll see that in the affected area, embedded gives error X0X95 and DerbyNetClient gives 42Y55. There are comments in the .sql (and thus in the .out files) that explain some of the difference in behavior; in derbyNetClient, the cursor (on the server) is already closed, and thus, the table gets dropped earlier. I wasn't familiar with this difference, so I looked up in the svn browser (starting at the top of trunk: http://svn.apache.org/viewvc/db/derby/ ) where these comments were added and found this change: http://svn.apache.org/viewvc?view=rev&revision=377367 . This refers to https://issues.apache.org/jira/browse/DERBY-821 , and there we can see Knut Anders' explanation for this difference. All that said, I have some misgivings on how you're approaching this conversion. There is already a hold-cursor junit test (...functionTests/tests/lang/holdCursorTest, from original holdCursorJava. Because there's such a clear reference to IJ I think the purpose of this test was to do some testing of the hold cursor functionality in ij. So, I'd suggest converting this test using the ScriptTest mechanism. Examples of how this can be done are: ...functionTests/tests/tools/ijRunScriptTest ...functionTests/tests/tools/ToolScripts ...functionTests/tests/nist/NistScripts ...functionTests/tests/derbynet/NetIjTest You'd have to find a way to make a separate comparison between NetworkServer/DerbyNetClient vs. Embedded. Maybe the easiest is to have two tests... Myrna
          Hide
          Junjie Peng added a comment -

          Myrna , thanks for your verbose advices!
          I'm still not so clear about:
          1. For my code in testDropTableWithOpenHoldCursor() Line 227-231,
          try

          { dropTable("t1"); }catch (SQLException e) { assertSQLState("X0X95", e); }
          which is in embed mode, when I want to drop a table with an open hold cursor, It should fail with a SQLException "X0X95 ". I have expected it ,but in fact, it prompts ".ComparisonFailure: Unexpected SQL state. ex
          pected:<42Y5...> but was:<X0X9...> ", why is it not ".ComparisonFailure: Unexpected SQL state. expected:<X0X95...> but was:<******.> " ?
          Furthermore, if I change the coed into
          try{ dropTable("t1"); }

          catch (SQLException e)

          { assertSQLState("0000", e); }

          The exception message is still "ComparisonFailure: Unexpected SQL state. expected:<42Y5...> but was:<X0X9...> ". why is it not "ComparisonFailure: Unexpected SQL state. expected:<0000.> but was:<******.> " ?
          Is there something wrong with my code?

          2. I have read through the four tools you mentioned. They are all good tools, but I feel puzzled, if translating holdCursorIJ.sql use tools, will we lose the junit view for this test on some degree?

          Thank you!
          Junjie

          Show
          Junjie Peng added a comment - Myrna , thanks for your verbose advices! I'm still not so clear about: 1. For my code in testDropTableWithOpenHoldCursor() Line 227-231, try { dropTable("t1"); }catch (SQLException e) { assertSQLState("X0X95", e); } which is in embed mode, when I want to drop a table with an open hold cursor, It should fail with a SQLException "X0X95 ". I have expected it ,but in fact, it prompts ".ComparisonFailure: Unexpected SQL state. ex pected:<42Y5...> but was:<X0X9...> ", why is it not ".ComparisonFailure: Unexpected SQL state. expected:<X0X95...> but was:<******.> " ? Furthermore, if I change the coed into try{ dropTable("t1"); } catch (SQLException e) { assertSQLState("0000", e); } The exception message is still "ComparisonFailure: Unexpected SQL state. expected:<42Y5...> but was:<X0X9...> ". why is it not "ComparisonFailure: Unexpected SQL state. expected:<0000.> but was:<******.> " ? Is there something wrong with my code? 2. I have read through the four tools you mentioned. They are all good tools, but I feel puzzled, if translating holdCursorIJ.sql use tools, will we lose the junit view for this test on some degree? Thank you! Junjie
          Hide
          Myrna van Lunteren added a comment -

          Hi Junjie,

          re 1. I see what you're asking now, sorry for the confusion earlier...The problem is that you were using the BaseJDBCTestCase method 'dropTable()'. This method "takes over" and the test doesn't get to check on the (if) resulting SQLException. In your block:
          ...
          }else{
          try

          { dropTable("t1"); }

          catch (SQLException e)

          { assertSQLState("X0X95", e); }

          The 'assertSQLState("X0X95",e); is never reached, instead, the assert in the stack trace is originating from the BaseJDBCTestCase.dropTable method.
          As you're expecting a specific error out of the drop table statement, you'd have to spell out the actual drop table statement, like you do elsewhere.

          re 2. The script mechanism still is junit. If you follow through from e.g. LangScripts.java you see the extending goes via ScriptTestCase<-CanonTestCase<-BaseJDBCTestCase. Most of the other junit tests for derby extend BaseJDBCTestCase. BaseJDBCTestCase extends BaseTestCase extends junit.framework.TestCase.

          Still, you raise a good point. Ideally, we'd not use master files, as the maintenance of those can get tedious. The CanonTestCase tests only work if there is only 1 master file, which is why in this case we'd have to do something special - the HoldCursorIJ test gives different results for embedded and DerbyNetClient...
          But to test language aspects specific to ij, this is the best the community has come up with.

          Maybe the best approach is to strip the ij/script test down so the .sql only does very basic testing of creating the cursors ('get ... cursor ...', 'next',...) which gives the same result for DerbyNetClient and embedded. The majority of test cases can then be added as fixtures to the existing HoldCursorTest.

          Show
          Myrna van Lunteren added a comment - Hi Junjie, re 1. I see what you're asking now, sorry for the confusion earlier...The problem is that you were using the BaseJDBCTestCase method 'dropTable()'. This method "takes over" and the test doesn't get to check on the (if) resulting SQLException. In your block: ... }else{ try { dropTable("t1"); } catch (SQLException e) { assertSQLState("X0X95", e); } The 'assertSQLState("X0X95",e); is never reached, instead, the assert in the stack trace is originating from the BaseJDBCTestCase.dropTable method. As you're expecting a specific error out of the drop table statement, you'd have to spell out the actual drop table statement, like you do elsewhere. re 2. The script mechanism still is junit. If you follow through from e.g. LangScripts.java you see the extending goes via ScriptTestCase<-CanonTestCase<-BaseJDBCTestCase. Most of the other junit tests for derby extend BaseJDBCTestCase. BaseJDBCTestCase extends BaseTestCase extends junit.framework.TestCase. Still, you raise a good point. Ideally, we'd not use master files, as the maintenance of those can get tedious. The CanonTestCase tests only work if there is only 1 master file, which is why in this case we'd have to do something special - the HoldCursorIJ test gives different results for embedded and DerbyNetClient... But to test language aspects specific to ij, this is the best the community has come up with. Maybe the best approach is to strip the ij/script test down so the .sql only does very basic testing of creating the cursors ('get ... cursor ...', 'next',...) which gives the same result for DerbyNetClient and embedded. The majority of test cases can then be added as fixtures to the existing HoldCursorTest.
          Hide
          Junjie Peng added a comment -

          Thanks, Myrna!
          I have looked into dropaTable(), and understood how it works. My first question is OK with your instruction.
          I agree with your comment "Maybe the best approach is to strip the ij/script test down so the .sql only does very basic testing of creating the cursors ('get ... cursor ...', 'next',...) which gives the same result for DerbyNetClient and embedded. The majority of test cases can then be added as fixtures to the existing HoldCursorTest. " However, I have a question:
          I have complete the whole translation in java code, may I post the patch instead of doing some translation with tools such as ScriptTestCase?

          Show
          Junjie Peng added a comment - Thanks, Myrna! I have looked into dropaTable(), and understood how it works. My first question is OK with your instruction. I agree with your comment "Maybe the best approach is to strip the ij/script test down so the .sql only does very basic testing of creating the cursors ('get ... cursor ...', 'next',...) which gives the same result for DerbyNetClient and embedded. The majority of test cases can then be added as fixtures to the existing HoldCursorTest. " However, I have a question: I have complete the whole translation in java code, may I post the patch instead of doing some translation with tools such as ScriptTestCase?
          Hide
          Myrna van Lunteren added a comment -

          For clarity sake it's probably better not to have too many ways of doing the same thing, but why don't you attach your patch and the community can decide whether it looks ok or not. I'll certainly take a look.

          Show
          Myrna van Lunteren added a comment - For clarity sake it's probably better not to have too many ways of doing the same thing, but why don't you attach your patch and the community can decide whether it looks ok or not. I'll certainly take a look.
          Hide
          Junjie Peng added a comment -

          Hi, Myrna!

          I have finished the translation, but something is wrong with the sixth test case, it's the method of testPositionedUpdateWithHoldCursor(). If it is deleted, the other test cases can run well. It seems, testPositionedUpdateWithHoldCursor() has not been execute to it's end, and then tearDown() begins to execute.

          I have spent a lot of time debugging, but still very puzzled, Please give me a hand!

          Thank you!

          Regard
          Junjie

          Show
          Junjie Peng added a comment - Hi, Myrna! I have finished the translation, but something is wrong with the sixth test case, it's the method of testPositionedUpdateWithHoldCursor(). If it is deleted, the other test cases can run well. It seems, testPositionedUpdateWithHoldCursor() has not been execute to it's end, and then tearDown() begins to execute. I have spent a lot of time debugging, but still very puzzled, Please give me a hand! Thank you! Regard Junjie
          Hide
          Myrna van Lunteren added a comment -

          I see you've made no attempt at creating a ScriptTest. I think you believe a ScriptTest is a 'tool' to convert the test to junit, and it may have started as a quick way to run certain .sql ways in junit, but it is currently the best way to execute the language constructs that are specific to ij.
          Yes, we have in the charter to use only standard SQL, but there are some extensions that are specific to Derby and they have to be tested also.

          Language clauses as "get cursor with hold", "next", "update where current of".
          So, it's important to keep a test that verifies appropriate behavior when such things are used in ij. Thus, we do need a HoldCursorIJTest, but it should be extending ScriptTestCase.

          However, the effort you made does not need to be thrown away - you should be able to identify which test cases (fixtures) in what you've converted now are suitable for adding to the existing HoldCursorTest, or maybe a HoldCursorTest2, and which ones should stay in .sql form to be run through a ScriptTestCase test called HoldCursorIJTest.
          Where there's a difference in behavior between Embedded and DerbyNetClient it cannot be run as a ScriptTestCase; those should be fixtures in a test without 'IJ' in the name.

          Now, for the fixture you had trouble with. I also had to look for a while before I spotted what was going on

          The fixture was failing (in multiple places) but because of the teardown, we'd never see the asserts; instead, all we'd see is complaints that the drop table t1 would not work.
          It would be better to not use the setUp() and teardown() methods and instead, use a decorateSQL() method. See other tests that use a cleanDatabaseTestSetup.

          Then, you made a tiny mistake in comparing after the first successful update - the expected value that gets updated is of the first row, not the second row. The expected value should be: "1","12"}, {"2","2". This mistake stays in all the assertFullResultSet calls.
          Further, the error message resulting from the failed attempt is different for DerbyNetClient in the converted format, it's no longer SQLState 24000.
          Then, the SQLState out of the call after the ResultSet has been closed is XCL16, not 42X30.

          Further, you missed checking the value after jdk4.next().
          Do something like
          assertEquals(1,rs.getInt(1));
          assertEquals(2, rs.getInt(2));

          Finally two nits:

          • I think the suite() method could be structured a bit differently, it was hard to figure out which tests were client only, embedded only, and which ones both.
          • Embedded is not always spelled with 'dd'
          Show
          Myrna van Lunteren added a comment - I see you've made no attempt at creating a ScriptTest. I think you believe a ScriptTest is a 'tool' to convert the test to junit, and it may have started as a quick way to run certain .sql ways in junit, but it is currently the best way to execute the language constructs that are specific to ij. Yes, we have in the charter to use only standard SQL, but there are some extensions that are specific to Derby and they have to be tested also. Language clauses as "get cursor with hold", "next", "update where current of". So, it's important to keep a test that verifies appropriate behavior when such things are used in ij. Thus, we do need a HoldCursorIJTest, but it should be extending ScriptTestCase. However, the effort you made does not need to be thrown away - you should be able to identify which test cases (fixtures) in what you've converted now are suitable for adding to the existing HoldCursorTest, or maybe a HoldCursorTest2, and which ones should stay in .sql form to be run through a ScriptTestCase test called HoldCursorIJTest. Where there's a difference in behavior between Embedded and DerbyNetClient it cannot be run as a ScriptTestCase; those should be fixtures in a test without 'IJ' in the name. Now, for the fixture you had trouble with. I also had to look for a while before I spotted what was going on The fixture was failing (in multiple places) but because of the teardown, we'd never see the asserts; instead, all we'd see is complaints that the drop table t1 would not work. It would be better to not use the setUp() and teardown() methods and instead, use a decorateSQL() method. See other tests that use a cleanDatabaseTestSetup. Then, you made a tiny mistake in comparing after the first successful update - the expected value that gets updated is of the first row, not the second row. The expected value should be: "1","12"}, {"2","2" . This mistake stays in all the assertFullResultSet calls. Further, the error message resulting from the failed attempt is different for DerbyNetClient in the converted format, it's no longer SQLState 24000. Then, the SQLState out of the call after the ResultSet has been closed is XCL16, not 42X30. Further, you missed checking the value after jdk4.next(). Do something like assertEquals(1,rs.getInt(1)); assertEquals(2, rs.getInt(2)); Finally two nits: I think the suite() method could be structured a bit differently, it was hard to figure out which tests were client only, embedded only, and which ones both. Embedded is not always spelled with 'dd'
          Hide
          Kathey Marsden added a comment -

          Unassigning this issue. I don't think Junjie is working on it now. Junjie, if I am mistaken, please reassign yourself.

          Show
          Kathey Marsden added a comment - Unassigning this issue. I don't think Junjie is working on it now. Junjie, if I am mistaken, please reassign yourself.
          Hide
          Tiago R. Espinha added a comment -

          Myrna,

          I have been working on this test conversion basing my work on Junjie's patch and have only now noticed that you had added useful comments to this issue.

          On this last comment of yours, you said:
          "...you should be able to identify which test cases (fixtures) in what you've converted now are suitable for adding to the existing HoldCursorTest..."

          Looking at the HoldCursorTest though, I can see that all of the cases where a dual behavior is required (for embedded and client/server) are actually already covered. There's only just one case that does not seem to be covered, but I think this is actually only useful for testing the ij syntax. The case is when we are trying the 'WITH CS' clause as follows:
          get with nohold cursor jdk1 as 'SELECT * FROM t1 WITH CS';

          So, to bottom-line this, I'm thinking of removing these fixtures from this HoldCursorIJTest (since they already exist in HoldCursorTest), extend it from ScriptTestCase and build on from that. I have never done one of these tests before but I should be able to get hints from other already existing tests with the same characteristics.

          Show
          Tiago R. Espinha added a comment - Myrna, I have been working on this test conversion basing my work on Junjie's patch and have only now noticed that you had added useful comments to this issue. On this last comment of yours, you said: "...you should be able to identify which test cases (fixtures) in what you've converted now are suitable for adding to the existing HoldCursorTest..." Looking at the HoldCursorTest though, I can see that all of the cases where a dual behavior is required (for embedded and client/server) are actually already covered. There's only just one case that does not seem to be covered, but I think this is actually only useful for testing the ij syntax. The case is when we are trying the 'WITH CS' clause as follows: get with nohold cursor jdk1 as 'SELECT * FROM t1 WITH CS'; So, to bottom-line this, I'm thinking of removing these fixtures from this HoldCursorIJTest (since they already exist in HoldCursorTest), extend it from ScriptTestCase and build on from that. I have never done one of these tests before but I should be able to get hints from other already existing tests with the same characteristics.
          Hide
          Myrna van Lunteren added a comment -

          That sounds good.
          I think the main thing to keep in mind going forward is to make sure we still test the syntax specific to ij.
          Perhaps it would even make sense to move the test to the tools directory? I can be convinced either way.

          Thanks for picking up this test conversion.

          Show
          Myrna van Lunteren added a comment - That sounds good. I think the main thing to keep in mind going forward is to make sure we still test the syntax specific to ij. Perhaps it would even make sense to move the test to the tools directory? I can be convinced either way. Thanks for picking up this test conversion.
          Hide
          Myrna van Lunteren added a comment -

          Tiago, looks like you're not actually working on this (anymore)? If you have saved some interim state of your efforts that would help a next person.

          Show
          Myrna van Lunteren added a comment - Tiago, looks like you're not actually working on this (anymore)? If you have saved some interim state of your efforts that would help a next person.
          Hide
          Tiago R. Espinha added a comment -

          Sorry Myrna for leaving this assigned.

          At this point I'm not working on it anymore, as I have a new GSoC project that I have applied with.

          I seem to have a patch for this issue in my trunk, but I am 100% sure that it is not meant for committing and should be taken with a grain of salt. Unfortunately I honestly can't remember anymore what I had done and what I hadn't, but I'll still attach it anyway.

          If whoever picks this up has any questions, I might be able to help somehow.

          Show
          Tiago R. Espinha added a comment - Sorry Myrna for leaving this assigned. At this point I'm not working on it anymore, as I have a new GSoC project that I have applied with. I seem to have a patch for this issue in my trunk, but I am 100% sure that it is not meant for committing and should be taken with a grain of salt. Unfortunately I honestly can't remember anymore what I had done and what I hadn't, but I'll still attach it anyway. If whoever picks this up has any questions, I might be able to help somehow.
          Hide
          Yun Lee added a comment -

          I would like to pick this issue! Junjie has done a lot of work on this issue, his work will help me a lot.

          After looking into the code, I think the current HoldCursorTest.java referred in Derby-2422 (https://issues.apache.org/jira/browse/DERBY-2422) can not do test on client mode expectably. I have attached a patch for this, please check it! Thanks!

          Show
          Yun Lee added a comment - I would like to pick this issue! Junjie has done a lot of work on this issue, his work will help me a lot. After looking into the code, I think the current HoldCursorTest.java referred in Derby-2422 ( https://issues.apache.org/jira/browse/DERBY-2422 ) can not do test on client mode expectably. I have attached a patch for this, please check it! Thanks!
          Hide
          Yun Lee added a comment -

          I have looked into this issue for some days, and done some converting in pure JUnit form. Eventually, I agreed with the first comment given by Myrna: "Because there's such a clear reference to IJ I think the purpose of this test was to do some testing of the hold cursor functionality in ij. So, I'd suggest converting this test using the ScriptTest mechanism", especially with Language clauses as "get cursor with hold", "next", "update where current of".

          Furthur, in my work, I've found, pure JUnit form will mask some details, for example, the detailed prompt for XCL16 in embeded mode is different from the one in ClientServer mode. The difference will be discarded in pure JUnit form, while clear in ScriptTest mechanism.

          I have attached derby-3801-4.patch, in which I have added HoldCursorIJTest extending ScriptTest to do tests on both mode of Derby.

          However, there's something wrong with subclasses of ScriptTest in my testing environment. When running HoldCursorIJTest, each of the tests fails because of a lot of messy codes '?'.

          D:\derby\test>java junit.textui.TestRunner org.apache.derbyTesting.functionTests
          .tests.lang.HoldCursorIJTest
          .F.F
          Time: 5.406
          There were 2 failures:
          1) holdCursorIJ(org.apache.derbyTesting.functionTests.tests.lang.HoldCursorIJTes
          t)junit.framework.ComparisonFailure: Output at line 19 expected:<[0 rows inserte
          d/updated/deleted]> but was:<[????????? 0 ?]>
          at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon
          (CanonTestCase.java:106)
          at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr
          iptTestCase.java:198)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          109)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
          )
          2) holdCursorIJ(org.apache.derbyTesting.functionTests.tests.lang.HoldCursorIJTes
          t)junit.framework.ComparisonFailure: Output at line 19 expected:<[0 rows inserte
          d/updated/deleted]> but was:<[????????? 0 ?]>
          at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon
          (CanonTestCase.java:106)
          at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr
          iptTestCase.java:198)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          109)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          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:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          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:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)

          FAILURES!!!
          Tests run: 2, Failures: 2, Errors: 0

          D:\derby\test>

          The similiar problem exists in other subclasses of ScriptTestCase, such as NistScripts,ToolScripts.

          Is this caused by the setting of Character encoding? How to resolve this problem?

          Thanks!

          Show
          Yun Lee added a comment - I have looked into this issue for some days, and done some converting in pure JUnit form. Eventually, I agreed with the first comment given by Myrna: "Because there's such a clear reference to IJ I think the purpose of this test was to do some testing of the hold cursor functionality in ij. So, I'd suggest converting this test using the ScriptTest mechanism", especially with Language clauses as "get cursor with hold", "next", "update where current of". Furthur, in my work, I've found, pure JUnit form will mask some details, for example, the detailed prompt for XCL16 in embeded mode is different from the one in ClientServer mode. The difference will be discarded in pure JUnit form, while clear in ScriptTest mechanism. I have attached derby-3801-4.patch, in which I have added HoldCursorIJTest extending ScriptTest to do tests on both mode of Derby. However, there's something wrong with subclasses of ScriptTest in my testing environment. When running HoldCursorIJTest, each of the tests fails because of a lot of messy codes '?'. D:\derby\test>java junit.textui.TestRunner org.apache.derbyTesting.functionTests .tests.lang.HoldCursorIJTest .F.F Time: 5.406 There were 2 failures: 1) holdCursorIJ(org.apache.derbyTesting.functionTests.tests.lang.HoldCursorIJTes t)junit.framework.ComparisonFailure: Output at line 19 expected:<[0 rows inserte d/updated/deleted]> but was:< [????????? 0 ?] > at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon (CanonTestCase.java:106) at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr iptTestCase.java:198) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57 ) 2) holdCursorIJ(org.apache.derbyTesting.functionTests.tests.lang.HoldCursorIJTes t)junit.framework.ComparisonFailure: Output at line 19 expected:<[0 rows inserte d/updated/deleted]> but was:< [????????? 0 ?] > at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon (CanonTestCase.java:106) at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr iptTestCase.java:198) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) 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:23) at junit.extensions.TestSetup.run(TestSetup.java:27) 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:23) at junit.extensions.TestSetup.run(TestSetup.java:27) FAILURES!!! Tests run: 2, Failures: 2, Errors: 0 D:\derby\test> The similiar problem exists in other subclasses of ScriptTestCase, such as NistScripts,ToolScripts. Is this caused by the setting of Character encoding? How to resolve this problem? Thanks!
          Hide
          Yun Lee added a comment -

          I'm sorry to have missed the patch. Attached it now!

          Show
          Yun Lee added a comment - I'm sorry to have missed the patch. Attached it now!
          Hide
          Kathey Marsden added a comment -

          Do you see other, already checked in tests fail? you might be able to force the issue by running with -Dfile.encoding=Cp1252, but I thought that the tests were careful to use a consistent encoding. I know that they pass on z/OS where the default encoding is different.

          Show
          Kathey Marsden added a comment - Do you see other, already checked in tests fail? you might be able to force the issue by running with -Dfile.encoding=Cp1252, but I thought that the tests were careful to use a consistent encoding. I know that they pass on z/OS where the default encoding is different.
          Hide
          Yun Lee added a comment -

          Yes, Kathey. I have tested many subclasses of ScriptTestCase, and all of them failed. I think it's related to Chinese character set, as I have seen Chinese chars when testing. As to "-Dfile.encoding=Cp1252", could you please show me where to insert it, it seems not correct to run a pure JUnit test class with RunTest.

          D:\derby\test>java -Dfile.encoding=Cp1252 org.apache.derbyTesting.functionTests
          .harness.RunTest derbynet/NetIjTest.java

              • Start: NetIjTest jdk1.5.0_16 2010-06-24 11:20:39 ***
                0 add
                > .F.F
                > There were 2 failures:
                > 1) -p(org.apache.derbyTesting.functionTests.tests.derbynet.NetIjTest)junit.fra
                mework.AssertionFailedError: SQL script missing: org/apache/derbyTesting/functio
                nTests/tests/derbynet/-p.sql
                > 2) D:\derby\test\NetIjTest\NetIjTest_app.properties(org.apache.derbyTesting.fu
                nctionTests.tests.derbynet.NetIjTest)junit.framework.AssertionFailedError: SQL s
                cript missing: org/apache/derbyTesting/functionTests/tests/derbynet/D:\derby\tes
                t\NetIjTest\NetIjTest_app.properties.sql
                > FAILURES!!!
                > Tests run: 2, Failures: 2, Errors: 0
                Test Failed.
              • End: NetIjTest jdk1.5.0_16 2010-06-24 11:20:43 ***

          D:\derby\test>java junit.textui.TestRunner org.apache.derbyTesting.functionTests
          .tests.derbynet.NetIjTest
          .F
          Time: 5.422
          There was 1 failure:
          1) testclientij(org.apache.derbyTesting.functionTests.tests.derbynet.NetIjTest)j
          unit.framework.ComparisonFailure: Output at line 34 expected:<[ERROR 42X05: Tabl
          e/View 'APP.NOTTHERE' does not exist.]> but was:<[?? 42X05????APP.NOTTHERE??
          ?]>
          at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon
          (CanonTestCase.java:106)
          at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr
          iptTestCase.java:198)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          109)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          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:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          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:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)

          FAILURES!!!
          Tests run: 1, Failures: 1, Errors: 0

          D:\derby\test>

          Show
          Yun Lee added a comment - Yes, Kathey. I have tested many subclasses of ScriptTestCase, and all of them failed. I think it's related to Chinese character set, as I have seen Chinese chars when testing. As to "-Dfile.encoding=Cp1252", could you please show me where to insert it, it seems not correct to run a pure JUnit test class with RunTest. D:\derby\test>java -Dfile.encoding=Cp1252 org.apache.derbyTesting.functionTests .harness.RunTest derbynet/NetIjTest.java Start: NetIjTest jdk1.5.0_16 2010-06-24 11:20:39 *** 0 add > .F.F > There were 2 failures: > 1) -p(org.apache.derbyTesting.functionTests.tests.derbynet.NetIjTest)junit.fra mework.AssertionFailedError: SQL script missing: org/apache/derbyTesting/functio nTests/tests/derbynet/-p.sql > 2) D:\derby\test\NetIjTest\NetIjTest_app.properties(org.apache.derbyTesting.fu nctionTests.tests.derbynet.NetIjTest)junit.framework.AssertionFailedError: SQL s cript missing: org/apache/derbyTesting/functionTests/tests/derbynet/D:\derby\tes t\NetIjTest\NetIjTest_app.properties.sql > FAILURES!!! > Tests run: 2, Failures: 2, Errors: 0 Test Failed. End: NetIjTest jdk1.5.0_16 2010-06-24 11:20:43 *** D:\derby\test>java junit.textui.TestRunner org.apache.derbyTesting.functionTests .tests.derbynet.NetIjTest .F Time: 5.422 There was 1 failure: 1) testclientij(org.apache.derbyTesting.functionTests.tests.derbynet.NetIjTest)j unit.framework.ComparisonFailure: Output at line 34 expected:<[ERROR 42X05: Tabl e/View 'APP.NOTTHERE' does not exist.]> but was:<[?? 42X05???? APP.NOTTHERE ?? ?]> at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon (CanonTestCase.java:106) at org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(Scr iptTestCase.java:198) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) 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:23) at junit.extensions.TestSetup.run(TestSetup.java:27) 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:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0 D:\derby\test>
          Hide
          Kathey Marsden added a comment -

          I think Rick is more likely on track with the locale than I was with the the encoding. If you confirm the Locale is the problem, perhaps the tests should set the default locale with
          Locale.setDefault(Locale.US) to avoid this problem for developers in the future. I don't know if it makes sense to set it and restore it within ScriptTestCase or do something more global. It would be good to open a separate issue for that fix.

          Show
          Kathey Marsden added a comment - I think Rick is more likely on track with the locale than I was with the the encoding. If you confirm the Locale is the problem, perhaps the tests should set the default locale with Locale.setDefault(Locale.US) to avoid this problem for developers in the future. I don't know if it makes sense to set it and restore it within ScriptTestCase or do something more global. It would be good to open a separate issue for that fix.
          Hide
          Yun Lee added a comment - - edited

          Please check derby-3801-5.patch, it can work well, thanks!

          As a subclass of ScriptTestCase can only process a canon file and the results of running holdCursorIJ.sql in two modes are different, I have created holdCursorIJ_client.sql and holdCursorIJ_embed.sql identifical with holdCursorIJ.sql, accordingly I've created holdCursorIJ_client.out and holdCursorIJ_embed.out.

          Show
          Yun Lee added a comment - - edited Please check derby-3801-5.patch, it can work well, thanks! As a subclass of ScriptTestCase can only process a canon file and the results of running holdCursorIJ.sql in two modes are different, I have created holdCursorIJ_client.sql and holdCursorIJ_embed.sql identifical with holdCursorIJ.sql, accordingly I've created holdCursorIJ_client.out and holdCursorIJ_embed.out.
          Hide
          Myrna van Lunteren added a comment -

          The .stat shows more files than appear to be in the .patch file; after applying the patch, I'm missing holdCursorIJ_embed.sql. The corresponding master file, holdCursorIJ_embed.out, appears based on an earlier version, but I cannot find such a file in the repository.

          And a final nit: functionTests/tests/lang/holdCursorIJ_app.properties can be deleted.

          Can you please generate a new patch? Please svn update before generating this new patch...

          Show
          Myrna van Lunteren added a comment - The .stat shows more files than appear to be in the .patch file; after applying the patch, I'm missing holdCursorIJ_embed.sql. The corresponding master file, holdCursorIJ_embed.out, appears based on an earlier version, but I cannot find such a file in the repository. And a final nit: functionTests/tests/lang/holdCursorIJ_app.properties can be deleted. Can you please generate a new patch? Please svn update before generating this new patch...
          Hide
          Yun Lee added a comment -

          Hi, Myrna. Thanks for your checking. I have created a new patch based on the newest revision. Please check it, thanks!

          Show
          Yun Lee added a comment - Hi, Myrna. Thanks for your checking. I have created a new patch based on the newest revision. Please check it, thanks!
          Hide
          Myrna van Lunteren added a comment -

          Thanks Yun, the patch applied cleanly this time.

          On closer consideration, I think there are still some issues.

          One of the purposes of converting the tests to junit is to eliminate the multiple masters. Multiple masters are troublesome to maintain, for every change needs to be duplicated.
          This background aspect was quite likely not clear from this issue...
          But keeping it in mind, you can see this goal has not been reached. There are still two masters, and in addition, there are now two identical scripts...And further, in addition to having LangScripts.java executing a list of sql scripts, there is now an additional separate script test executing 2 scripts...

          I don't think this is the way to go.

          A better way to approach this, would be to look at the differences between output for embedded and network server, and eliminate these from the .sql file.

          In the long run, that would be by fixing the differences, but in the short term, for each difference, you should log a bug for the difference in behavior, and link the bug to DERBY-310 (master for embedded/network server differences). Then, for each difference, you should create a non-ij junit test case - where possible in an existing test, and remove the section from the ij script.
          The endresult would be a sql test case that gives the same output with embedded as network server, and that can be added to the list of tests in LangScripts.java.

          I can see 6 differences between holdCursorIJ.out and DerbyNetClient/holdCursorIJ.out (we can safely ignore DerbyNet/holdCursorIJ.out - IBM no longer supports that driver with the latest versions of derby).
          1. displaywidth differences. This is documented in DERBY-1371, and is marked as won't fix. Nothing to do there - the conversion to junit takes care of those diffs.
          2. difference in text for Error message XCL16 between client and embedded.
          This should get corrected by making the messages identical.
          I did not find an existing bug on this issue.
          You should log a new bug (improvement) for this difference (and link it to DERBY-301).
          I took a superficial look, and it seems to me that it might be possible to figure out the operations in which CLIENT_RESULT_SET_NOT_OPEN (XCL16.S.1 in loc.messages.xml and shared.common.reference.SQLState.java) is generated, and pass them on.
          A separate test case (test cases) should be added in some junit test somewhere.
          3. drop table fails with embedded because resultset is open (and 3 subsequent differences)
          This is probably the result of the fact that data gets prefetched on the server.
          I am not certain whether there is a bug here or not. The prefetching is ok, that's documented intended behavior, but should the cursors be closed? A bug should be logged for this.
          Anyway, there's nothing in particular ij about this part of the test. The test case should be pulled out into a (existing?) junit test to show this difference, and just remove that part from the script (that is, close the cursors, then drop the table).
          4. change of isolation level succeeds with client because cursor is already closed.
          Again, should the cursor be closed? It's really the same kind of issue as of difference 3.
          A new bug should be logged, the test case showing the difference should get added to a different test, and the ij test script should be massaged so that client and embedded give the same output.
          5. error message difference - XJ202 on client (invalid cursorname) vs. 42X30 (cursor not found) with embedded. Again, a new bug can be logged, the test case extracted, and removed from the holdCursorIJ script. The specific language syntax is tested already in the script, just before.
          6. error 24000 with embedded, update successful with client.
          The difference so far are only minor bugs, but this one looks a bit more serious.
          It appears, that the client may be doing this wrong - DERBY-610 was logged against embedded but was found to behave correctly.
          Again, that section of the test should go into a separate junit test case somewhere.
          Or it can be commented out for the time being in the holdCursorIJ script.

          Once these bugs have been created, and the subtests have found a new home, there should be only one 'holdCursorIJ.sql' script; this can then be added to LangScripts.java.

          And - final nit - the converted test needs to be removed from functionTests/suites/derbylang.runall and functionTests/suites/derbynetmats.runall.

          I realize you've put some effort into this issue (you did note the XCL16 difference before), and it's aggravating that now there's a lot more work. But it's shown to be part of the conversion trouble that we often do expose more issues during the conversion, and I feel the end result will be a better maintainable test set.

          Show
          Myrna van Lunteren added a comment - Thanks Yun, the patch applied cleanly this time. On closer consideration, I think there are still some issues. One of the purposes of converting the tests to junit is to eliminate the multiple masters. Multiple masters are troublesome to maintain, for every change needs to be duplicated. This background aspect was quite likely not clear from this issue... But keeping it in mind, you can see this goal has not been reached. There are still two masters, and in addition, there are now two identical scripts...And further, in addition to having LangScripts.java executing a list of sql scripts, there is now an additional separate script test executing 2 scripts... I don't think this is the way to go. A better way to approach this, would be to look at the differences between output for embedded and network server, and eliminate these from the .sql file. In the long run, that would be by fixing the differences, but in the short term, for each difference, you should log a bug for the difference in behavior, and link the bug to DERBY-310 (master for embedded/network server differences). Then, for each difference, you should create a non-ij junit test case - where possible in an existing test, and remove the section from the ij script. The endresult would be a sql test case that gives the same output with embedded as network server, and that can be added to the list of tests in LangScripts.java. I can see 6 differences between holdCursorIJ.out and DerbyNetClient/holdCursorIJ.out (we can safely ignore DerbyNet/holdCursorIJ.out - IBM no longer supports that driver with the latest versions of derby). 1. displaywidth differences. This is documented in DERBY-1371 , and is marked as won't fix. Nothing to do there - the conversion to junit takes care of those diffs. 2. difference in text for Error message XCL16 between client and embedded. This should get corrected by making the messages identical. I did not find an existing bug on this issue. You should log a new bug (improvement) for this difference (and link it to DERBY-301 ). I took a superficial look, and it seems to me that it might be possible to figure out the operations in which CLIENT_RESULT_SET_NOT_OPEN (XCL16.S.1 in loc.messages.xml and shared.common.reference.SQLState.java) is generated, and pass them on. A separate test case (test cases) should be added in some junit test somewhere. 3. drop table fails with embedded because resultset is open (and 3 subsequent differences) This is probably the result of the fact that data gets prefetched on the server. I am not certain whether there is a bug here or not. The prefetching is ok, that's documented intended behavior, but should the cursors be closed? A bug should be logged for this. Anyway, there's nothing in particular ij about this part of the test. The test case should be pulled out into a (existing?) junit test to show this difference, and just remove that part from the script (that is, close the cursors, then drop the table). 4. change of isolation level succeeds with client because cursor is already closed. Again, should the cursor be closed? It's really the same kind of issue as of difference 3. A new bug should be logged, the test case showing the difference should get added to a different test, and the ij test script should be massaged so that client and embedded give the same output. 5. error message difference - XJ202 on client (invalid cursorname) vs. 42X30 (cursor not found) with embedded. Again, a new bug can be logged, the test case extracted, and removed from the holdCursorIJ script. The specific language syntax is tested already in the script, just before. 6. error 24000 with embedded, update successful with client. The difference so far are only minor bugs, but this one looks a bit more serious. It appears, that the client may be doing this wrong - DERBY-610 was logged against embedded but was found to behave correctly. Again, that section of the test should go into a separate junit test case somewhere. Or it can be commented out for the time being in the holdCursorIJ script. Once these bugs have been created, and the subtests have found a new home, there should be only one 'holdCursorIJ.sql' script; this can then be added to LangScripts.java. And - final nit - the converted test needs to be removed from functionTests/suites/derbylang.runall and functionTests/suites/derbynetmats.runall. I realize you've put some effort into this issue (you did note the XCL16 difference before), and it's aggravating that now there's a lot more work. But it's shown to be part of the conversion trouble that we often do expose more issues during the conversion, and I feel the end result will be a better maintainable test set.
          Hide
          Yun Lee added a comment -

          Thanks for your detailed advice, Myrna. I would love to push the work forward. I will create issues, and DERBY-3801 itself will be blocked until the new issues are resolved.

          Show
          Yun Lee added a comment - Thanks for your detailed advice, Myrna. I would love to push the work forward. I will create issues, and DERBY-3801 itself will be blocked until the new issues are resolved.
          Hide
          Yun Lee added a comment -

          I have created DERBY-4767 for Error message XCL16.

          As you said
          "2. difference in text for Error message XCL16 between client and embedded.
          This should get corrected by making the messages identical.
          I did not find an existing bug on this issue.
          You should log a new bug (improvement) for this difference (and link it to DERBY-301).
          I took a superficial look, and it seems to me that it might be possible to figure out the operations in which CLIENT_RESULT_SET_NOT_OPEN (XCL16.S.1 in loc.messages.xml and shared.common.reference.SQLState.java) is generated, and pass them on.
          A separate test case (test cases) should be added in some junit test somewhere. "

          I have a question about this. Need I change Derby client code to match behavior with Embedded driver? Does it mean that in this issue, CLIENT_RESULT_SET_NOT_OPEN(XCL16.S.1) should be replaced by LANG_RESULT_SET_NOT_OPEN(XCL16.S.0)? And then, why did DERBY created two different(but very similiar) messages?

          Show
          Yun Lee added a comment - I have created DERBY-4767 for Error message XCL16. As you said "2. difference in text for Error message XCL16 between client and embedded. This should get corrected by making the messages identical. I did not find an existing bug on this issue. You should log a new bug (improvement) for this difference (and link it to DERBY-301 ). I took a superficial look, and it seems to me that it might be possible to figure out the operations in which CLIENT_RESULT_SET_NOT_OPEN (XCL16.S.1 in loc.messages.xml and shared.common.reference.SQLState.java) is generated, and pass them on. A separate test case (test cases) should be added in some junit test somewhere. " I have a question about this. Need I change Derby client code to match behavior with Embedded driver? Does it mean that in this issue, CLIENT_RESULT_SET_NOT_OPEN(XCL16.S.1) should be replaced by LANG_RESULT_SET_NOT_OPEN(XCL16.S.0)? And then, why did DERBY created two different(but very similiar) messages?
          Hide
          Yun Lee added a comment -

          Hi, Myrna. I have a question on this comment snippet.

          "3. drop table fails with embedded because resultset is open (and 3 subsequent differences)
          This is probably the result of the fact that data gets prefetched on the server.
          I am not certain whether there is a bug here or not. The prefetching is ok, that's documented intended behavior, but should the cursors be closed? A bug should be logged for this.
          Anyway, there's nothing in particular ij about this part of the test. The test case should be pulled out into a (existing?) junit test to show this difference, and just remove that part from the script (that is, close the cursors, then drop the table). "

          However, in line 206 of org.apache.derbyTesting.functionTests.tests.lang.HoldCursorTest, we see the testDropTable() method.
          public void testDropTable() throws SQLException

          { setHoldability(ResultSet.HOLD_CURSORS_OVER_COMMIT); final String dropTable = "DROP TABLE T1"; Statement stmt1 = createStatement(); Statement stmt2 = createStatement(); ResultSet rs = stmt1.executeQuery("SELECT * FROM T1"); rs.next(); assertStatementError("X0X95", stmt2,dropTable); // dropping t1 should fail because there is an open cursor on t1 assertStatementError("X0X95", stmt2,dropTable); commit(); // cursors are held over commit, so dropping should still fail assertStatementError("X0X95", stmt2,dropTable); rs.close(); // cursor is closed, so this one should succeed stmt2.executeUpdate(dropTable); stmt1.close(); stmt2.close(); rollback(); }

          Here, DERBY performs the same in both mode. Does the difference just occur in IJ or is there any other configuration to trigger it?

          Show
          Yun Lee added a comment - Hi, Myrna. I have a question on this comment snippet. "3. drop table fails with embedded because resultset is open (and 3 subsequent differences) This is probably the result of the fact that data gets prefetched on the server. I am not certain whether there is a bug here or not. The prefetching is ok, that's documented intended behavior, but should the cursors be closed? A bug should be logged for this. Anyway, there's nothing in particular ij about this part of the test. The test case should be pulled out into a (existing?) junit test to show this difference, and just remove that part from the script (that is, close the cursors, then drop the table). " However, in line 206 of org.apache.derbyTesting.functionTests.tests.lang.HoldCursorTest, we see the testDropTable() method. public void testDropTable() throws SQLException { setHoldability(ResultSet.HOLD_CURSORS_OVER_COMMIT); final String dropTable = "DROP TABLE T1"; Statement stmt1 = createStatement(); Statement stmt2 = createStatement(); ResultSet rs = stmt1.executeQuery("SELECT * FROM T1"); rs.next(); assertStatementError("X0X95", stmt2,dropTable); // dropping t1 should fail because there is an open cursor on t1 assertStatementError("X0X95", stmt2,dropTable); commit(); // cursors are held over commit, so dropping should still fail assertStatementError("X0X95", stmt2,dropTable); rs.close(); // cursor is closed, so this one should succeed stmt2.executeUpdate(dropTable); stmt1.close(); stmt2.close(); rollback(); } Here, DERBY performs the same in both mode. Does the difference just occur in IJ or is there any other configuration to trigger it?
          Hide
          Yun Lee added a comment -

          You have commented:
          "4. change of isolation level succeeds with client because cursor is already closed.
          Again, should the cursor be closed? It's really the same kind of issue as of difference 3.
          A new bug should be logged, the test case showing the difference should get added to a different test, and the ij test script should be massaged so that client and embedded give the same output. "

          However, in testSetTransactionIsolationInHoldCursor() method of org.apache.derbyTesting.functionTests.tests.jdbcapi.SetTransactionIsolationTest,,
          " /**

          • Call setTransactionIsolation with holdable cursor open?
            */
            public void testSetTransactionIsolationInHoldCursor() throws SQLException

          {
          Connection conn = getConnection();
          try

          { PreparedStatement ps = conn.prepareStatement("SELECT * from TAB1"); ResultSet rs = ps.executeQuery(); rs.next(); // setTransactionIsolation should fail because we have // a holdable cursor open conn .setTransactionIsolation(java.sql.Connection.TRANSACTION_SERIALIZABLE); rs.next(); // to fix DERBY-1108. Else the GC for ibm15 will clean // up the ResultSet Object }

          catch (SQLException se)

          { assertSQLState("Expected Exception if held cursor is open", "X0X03", se); return; }

          fail("FAIL: setTransactionIsolation() did not throw exception with open hold cursor");
          }"

          Here, DERBY performs the same in both mode. Does the difference just occur in IJ or is there any other configuration to trigger it?

          Show
          Yun Lee added a comment - You have commented: "4. change of isolation level succeeds with client because cursor is already closed. Again, should the cursor be closed? It's really the same kind of issue as of difference 3. A new bug should be logged, the test case showing the difference should get added to a different test, and the ij test script should be massaged so that client and embedded give the same output. " However, in testSetTransactionIsolationInHoldCursor() method of org.apache.derbyTesting.functionTests.tests.jdbcapi.SetTransactionIsolationTest,, " /** Call setTransactionIsolation with holdable cursor open? */ public void testSetTransactionIsolationInHoldCursor() throws SQLException { Connection conn = getConnection(); try { PreparedStatement ps = conn.prepareStatement("SELECT * from TAB1"); ResultSet rs = ps.executeQuery(); rs.next(); // setTransactionIsolation should fail because we have // a holdable cursor open conn .setTransactionIsolation(java.sql.Connection.TRANSACTION_SERIALIZABLE); rs.next(); // to fix DERBY-1108. Else the GC for ibm15 will clean // up the ResultSet Object } catch (SQLException se) { assertSQLState("Expected Exception if held cursor is open", "X0X03", se); return; } fail("FAIL: setTransactionIsolation() did not throw exception with open hold cursor"); }" Here, DERBY performs the same in both mode. Does the difference just occur in IJ or is there any other configuration to trigger it?
          Hide
          Myrna van Lunteren added a comment -

          Hi Yun,

          Those are good finds.

          The difference is in the data - in the holdCursorIJ.sql test, there are only 2 tiny rows in the table.
          In the junit tests, the tables both have many rows. The prefetching is done in chunks of 32K.
          So, in the ij test, the entire table is prefetched by the server; in the junit tests you found, the prefetch is done, but there's more data, so the cursor must stay open.

          (I verified the behavior by making a copy of the two fixtures you found, but with the following table:
          create table smallt1 (c1 int, c2 int);
          insert into smallt1 values(1, 1);
          insert into smallt1 values(2, 2);
          and indeed, the tests then failed for network server, indicating no error was thrown).

          Thus, the difference is not a bug, and as you found areas where they're being tested, you can safely remove those test cases from the HoldCursorIJ script.

          Show
          Myrna van Lunteren added a comment - Hi Yun, Those are good finds. The difference is in the data - in the holdCursorIJ.sql test, there are only 2 tiny rows in the table. In the junit tests, the tables both have many rows. The prefetching is done in chunks of 32K. So, in the ij test, the entire table is prefetched by the server; in the junit tests you found, the prefetch is done, but there's more data, so the cursor must stay open. (I verified the behavior by making a copy of the two fixtures you found, but with the following table: create table smallt1 (c1 int, c2 int); insert into smallt1 values(1, 1); insert into smallt1 values(2, 2); and indeed, the tests then failed for network server, indicating no error was thrown). Thus, the difference is not a bug, and as you found areas where they're being tested, you can safely remove those test cases from the HoldCursorIJ script.
          Hide
          Yun Lee added a comment -

          Hi, Myrna. I also created Issue DERBY-4777 fro difference 5 and sumitted a patch, please check it, thanks!

          Show
          Yun Lee added a comment - Hi, Myrna. I also created Issue DERBY-4777 fro difference 5 and sumitted a patch, please check it, thanks!
          Hide
          Yun Lee added a comment -

          I have also created DERBY-4778 for difference 6, but I don't know where is the entry for it. Please give some advice, thanks very much!

          Show
          Yun Lee added a comment - I have also created DERBY-4778 for difference 6, but I don't know where is the entry for it. Please give some advice, thanks very much!
          Hide
          Myrna van Lunteren added a comment -

          Attaching a patch for this issue which takes advantage of the fixes for DERBY-4776 and DERBY-4777, and in which the other tests sections that showed a difference between client and embedded have been removed (as they were found to be no bugs, or at least, known behavior, and the tests were also already executed in junit tests elsewhere), and in one case commented out (for DERBY-4778).

          If there are no concerns about this, I'll commit this in the next couple of days.

          Show
          Myrna van Lunteren added a comment - Attaching a patch for this issue which takes advantage of the fixes for DERBY-4776 and DERBY-4777 , and in which the other tests sections that showed a difference between client and embedded have been removed (as they were found to be no bugs, or at least, known behavior, and the tests were also already executed in junit tests elsewhere), and in one case commented out (for DERBY-4778 ). If there are no concerns about this, I'll commit this in the next couple of days.
          Hide
          Myrna van Lunteren added a comment -

          I committed by patch derby-3801-7. resolving this issue.

          Show
          Myrna van Lunteren added a comment - I committed by patch derby-3801-7. resolving this issue.
          Hide
          Myrna van Lunteren added a comment -

          closing. I don't think Junjie monitors the list.

          Show
          Myrna van Lunteren added a comment - closing. I don't think Junjie monitors the list.

            People

            • Assignee:
              Yun Lee
              Reporter:
              Junjie Peng
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development