db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Created: (DERBY-3573) Argument checking for ResultSet.setFetchSize(int) is incorrect
Date Thu, 27 Mar 2008 20:37:50 GMT
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


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

View raw message