[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898931#action_12898931 ] Yun Lee commented on DERBY-3801: 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! > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, derby-3801-5.patch, derby-3801-5.stat, > derby-3801-6.patch, derby-3801-6.stat, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898917#action_12898917 ] Yun Lee commented on DERBY-3801: Hi, Myrna. I also created Issue DERBY-4777 fro difference 5 and sumitted a patch, please check it, thanks! > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, derby-3801-5.patch, derby-3801-5.stat, > derby-3801-6.patch, derby-3801-6.stat, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898500#action_12898500 ] Myrna van Lunteren commented on DERBY-3801: --- 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. > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, derby-3801-5.patch, derby-3801-5.stat, > derby-3801-6.patch, derby-3801-6.stat, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[
https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898188#action_12898188
]
Yun Lee commented on DERBY-3801:
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?
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
> --
>
> Key: DERBY-3801
> URL: https://issues.apache.org/jira/browse/DERBY-3801
> Project: Derby
> Issue Type: Improvement
> Components: Test
>Reporter: Junjie Peng
>Assignee: Yun Lee
> Attachments: derby-3801-1-patch.txt, derby-3801-2.patch,
> derby-3801-2.stat, derby-3801-4.patch, derby-3801-5.patch, derby-3801-5.stat,
> derby-3801-6.patch, derby-3801-6.stat, DERBY-3801-Tiago.patch
>
>
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[
https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898179#action_12898179
]
Yun Lee commented on DERBY-3801:
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?
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
> --
>
> Key: DERBY-3801
> URL: https://issues.apache.org/jira/browse/DERBY-3801
> Project: Derby
> Issue Type: Improvement
> Components: Test
>Reporter: Junjie Peng
>Assignee: Yun Lee
> Attachments: derby-3801-1-patch.txt, derby-3801-2.patch,
> derby-3801-2.stat, derby-3801-4.patch, derby-3801-5.patch, derby-3801-5.stat,
> derby-3801-6.patch, derby-3801-6.stat, DERBY-3801-Tiago.patch
>
>
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12897269#action_12897269 ] Yun Lee commented on DERBY-3801: 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? > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, derby-3801-5.patch, derby-3801-5.stat, > derby-3801-6.patch, derby-3801-6.stat, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12897243#action_12897243 ] Yun Lee commented on DERBY-3801: 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. > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, derby-3801-5.patch, derby-3801-5.stat, > derby-3801-6.patch, derby-3801-6.stat, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12897077#action_12897077 ] Myrna van Lunteren commented on DERBY-3801: --- 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 th
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896712#action_12896712 ] Myrna van Lunteren commented on DERBY-3801: --- 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... > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, derby-3801-5.patch, derby-3801-5.stat, > DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882179#action_12882179 ] Kathey Marsden commented on DERBY-3801: --- 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. > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882018#action_12882018 ] Yun Lee commented on DERBY-3801: 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> > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881960#action_12881960 ] Kathey Marsden commented on DERBY-3801: --- 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. > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, derby-3801-4.patch, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881135#action_12881135 ] Yun Lee commented on DERBY-3801: 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! > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880629#action_12880629 ] Yun Lee commented on DERBY-3801: 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! > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Yun Lee > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat, DERBY-3801-Tiago.patch > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857513#action_12857513 ] Myrna van Lunteren commented on DERBY-3801: --- 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. > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Tiago R. Espinha > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742607#action_12742607 ] Myrna van Lunteren commented on DERBY-3801: --- 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. > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Tiago R. Espinha > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742567#action_12742567 ] Tiago R. Espinha commented on DERBY-3801: - 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. > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Improvement > Components: Test >Reporter: Junjie Peng >Assignee: Tiago R. Espinha > Attachments: derby-3801-1-patch.txt, derby-3801-2.patch, > derby-3801-2.stat > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[
https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625546#action_12625546
]
Myrna van Lunteren commented on DERBY-3801:
---
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'
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
> --
>
> Key: DERBY-3801
> URL: https://issues.apache.org/jira/browse/DERBY-3801
> Project: Derby
> Issue Type: Test
>Reporter: Junjie Peng
>Assignee: Junjie Peng
> Attachments: derby-3801-1-patch.txt, derby-3801-2.patch,
> derby-3801-2.stat
>
>
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619903#action_12619903 ] Myrna van Lunteren commented on DERBY-3801: --- 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. > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Test >Reporter: Junjie Peng >Assignee: Junjie Peng > Attachments: derby-3801-1-patch.txt > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[
https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619770#action_12619770
]
Junjie Peng commented on DERBY-3801:
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?
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
> --
>
> Key: DERBY-3801
> URL: https://issues.apache.org/jira/browse/DERBY-3801
> Project: Derby
> Issue Type: Test
>Reporter: Junjie Peng
>Assignee: Junjie Peng
> Attachments: derby-3801-1-patch.txt
>
>
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[
https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619730#action_12619730
]
Myrna van Lunteren commented on DERBY-3801:
---
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.
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
> --
>
> Key: DERBY-3801
> URL: https://issues.apache.org/jira/browse/DERBY-3801
> Project: Derby
> Issue Type: Test
>Reporter: Junjie Peng
>Assignee: Junjie Peng
> Attachments: derby-3801-1-patch.txt
>
>
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[
https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619044#action_12619044
]
Junjie Peng commented on DERBY-3801:
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: ", why is it not ".ComparisonFailure:
Unexpected SQL state. expected: but was:<**.> " ?
Furthermore, if I change the coed into
try{
dropTable("t1");
}catch (SQLException e) {
assertSQLState("", e);
}
The exception message is still "ComparisonFailure: Unexpected SQL state.
expected:<42Y5...> but was: ". why is it not "ComparisonFailure:
Unexpected SQL state. expected:<.> 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
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
> --
>
> Key: DERBY-3801
> URL: https://issues.apache.org/jira/browse/DERBY-3801
> Project: Derby
> Issue Type: Test
>Reporter: Junjie Peng
>Assignee: Junjie Peng
> Attachments: derby-3801-1-patch.txt
>
>
> Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql"
> to junit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
[ https://issues.apache.org/jira/browse/DERBY-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618901#action_12618901 ] Myrna van Lunteren commented on DERBY-3801: --- 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 > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. > -- > > Key: DERBY-3801 > URL: https://issues.apache.org/jira/browse/DERBY-3801 > Project: Derby > Issue Type: Test >Reporter: Junjie Peng >Assignee: Junjie Peng > Attachments: derby-3801-1-patch.txt > > > Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" > to junit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
