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