db-derby-dev mailing list archives

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

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


Mime
View raw message