[
https://issues.apache.org/jira/browse/DERBY-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794061#comment-13794061
]
ASF subversion and git services commented on DERBY-3573:
--------------------------------------------------------
Commit 1531854 from [~dyret] in branch 'code/trunk'
[ https://svn.apache.org/r1531854 ]
DERBY-3573: Remove incorrect check against maxRows when setting fetchSize.
Patch contributed by Nirmal Fernando.
> 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
> Assignee: Nirmal Fernando
> Priority: Minor
> Labels: derby_triage10_8, patch
> Attachments: derby-3573-a.diff, derby-3573-b.diff,
> derby-3573-test.diff
>
>
> 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 was sent by Atlassian JIRA
(v6.1#6144)
