[jira] Created: (DERBY-3573) Argument checking for ResultSet.setFetchSize(int) is incorrect

Argument checking for ResultSet.setFetchSize(int) is incorrect
--------------------------------------------------------------

                 Key: DERBY-3573
                 URL: https://issues.apache.org/jira/browse/DERBY-3573
             Project: Derby
          Issue Type: Bug
          Components: JDBC, Network Client, Newcomer
    Affects Versions: 10.3.2.1, 10.3.1.4
            Reporter: Dyre Tjeldvoll
            Priority: Minor


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)?

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

[Lance J. Andersen]

Yes, it was an EG decision to correct the javadocs for setFetchSize()  as if there is no limit specified via setMaxRows(),  getMaxRows() returns 0 thus  using:

0 <= rows <= this.getMaxRows()

 can be problematic depending on implementations.

Also setFetchSize is a hint and can be ignored


Regards
Lance

Dyre Tjeldvoll (JIRA) wrote:

Argument checking for ResultSet.setFetchSize(int) is incorrect
--------------------------------------------------------------

                 Key: DERBY-3573
                 URL: https://issues.apache.org/jira/browse/DERBY-3573
             Project: Derby
          Issue Type: Bug
          Components: JDBC, Network Client, Newcomer
    Affects Versions: 10.3.2.1, 10.3.1.4
            Reporter: Dyre Tjeldvoll
            Priority: Minor


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)?

  

     [ https://issues.apache.org/jira/browse/DERBY-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiago R. Espinha updated DERBY-3573:
------------------------------------


Triaged for 10.5.2. No changes made.

> Argument checking for ResultSet.setFetchSize(int) is incorrect
> --------------------------------------------------------------
>
>                 Key: DERBY-3573
>                 URL: https://issues.apache.org/jira/browse/DERBY-3573
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions: 10.3.1.4, 10.3.2.1
>            Reporter: Dyre Tjeldvoll
>            Priority: Minor
>
> 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)?

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