db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3203) Convert jdbcapi/statementJdbc20.java to JUnit
Date Fri, 07 Dec 2007 17:18:43 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549477

Dyre Tjeldvoll commented on DERBY-3203:

I think I have resolved the apparent mystery here. The requirement that the argument to ResultSet.setFetchSize(int)
be less than Statement.getMaxRows() was dropped in Java 6/JDBC 4, (it is not present in the
Java 6 javadoc, but can still be seen in the Java 5 javadoc).

The reason why the client driver doesn't throw an exception in this case is because am.ResultSet
incorrectly checks against ResultSet.maxRows_ and NOT am.Statement.getMaxRows(). So when am.Statement.setMaxRows(int)
is called after a result set has already been created, am.ResultSet.setFechSize(int) will
check against a stale value.

The question is what to do about this. The client driver clearly has a bug, but should we
fix it by duplicating the old behavior found in the embedded driver, or change both drivers
to comply with latest spec which allows any non-negative value as argument to ResultSet.setFetchSize(int)?

> Convert jdbcapi/statementJdbc20.java to JUnit
> ---------------------------------------------
>                 Key: DERBY-3203
>                 URL: https://issues.apache.org/jira/browse/DERBY-3203
>             Project: Derby
>          Issue Type: Test
>            Reporter: Ramin Moazeni
>            Assignee: Ramin Moazeni
>             Fix For:
>         Attachments: DERBY-3203v0.diff, DERBY-3203v0.stat, DERBY-3203v2.diff, DERBY-3203v3.diff
> This issue is creates for converting jdbcapi/statementJdbc20.java to JUnit.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message