db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3801) Convert "org.apache.derbyTesting.functionTests.tests.lang.holdCursorIJ.sql" to junit.
Date Tue, 10 Aug 2010 22:59:16 GMT

    [ 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 the conversion, and I feel the end result
will be a better maintainable test set.

> 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.


Mime
View raw message