[
https://issues.apache.org/jira/browse/DERBY-4251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew McRae updated DERBY-4251:
--------------------------------
Description:
According to source of the Derby version I first found it in, and the version
just released today, here is the offending code:
https://svn.apache.org/repos/asf/db/derby/code/tags/10.5.1.1/java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
{quote}
public int getRow() throws SQLException {
// getRow() is only allowed on scroll cursors
checkScrollCursor("getRow()");
/*
* * We probably needn't bother getting the text of * the
underlying
* statement but it is better to be * consistent and we aren't
* particularly worried * about performance of getRow().
*/
return theResults.getRowNumber();
}
{quote}
The comment and the check for scrollability is incorrect. The Javadoc comment
for this getRow is a duplicate of the Sun JDK API for ResultSet.getRow(), and
if the author had just written it according to their own javadoc there would be
no problem.
See spec here:
http://java.sun.com/j2se/1.3/docs/api/java/sql/ResultSet.html#getRow()
The Sun Javadoc does not spell out any exceptions to the required behaviour.
getRow should always work regardless of whether the result set is scrollable
because the issue of scrollability is whether the client can *reposition* the
cursor to change the current row of the result set. Simply *reading* the
current row number is different and unrelated to changing the current row
number.
Therefore getRow() should work for FORWARD_ONLY ResultSets, but Derby currently
fails on this.
Quite aside from the spec nonconformance, it's a bit annoying that my
application has worked fine on Oracle, MS SQL, the JDBC-LDAP bridge driver, and
even MS Access MDB files via the Sun JDBC-ODBC bridge driver, but then the
Derby engine falls over just trying to run a simple Select statement on a
non-updatable forward-only result set - the simplest kind of all!
I haven't looked at what " theResults.getRowNumber() " does, but I hope the fix
for this bug is as simple as removing the call to checkScrollCursor;
was:
According to source of the Derby version I first found it in, and the version
just released today, here is the offending code:
https://svn.apache.org/repos/asf/db/derby/code/tags/10.5.1.1/java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
{quote}
{{
public int getRow() throws SQLException {
// getRow() is only allowed on scroll cursors
checkScrollCursor("getRow()");
/*
* * We probably needn't bother getting the text of * the
underlying
* statement but it is better to be * consistent and we aren't
* particularly worried * about performance of getRow().
*/
return theResults.getRowNumber();
}
}}
{quote}
The comment and the check for scrollability is incorrect. The Javadoc comment
for this getRow is a duplicate of the Sun JDK API for ResultSet.getRow(), and
if the author had just written it according to their own javadoc there would be
no problem.
See spec here:
http://java.sun.com/j2se/1.3/docs/api/java/sql/ResultSet.html#getRow()
The Sun Javadoc does not spell out any exceptions to the required behaviour.
getRow should always work regardless of whether the result set is scrollable
because the issue of scrollability is whether the client can *reposition* the
cursor to change the current row of the result set. Simply *reading* the
current row number is different and unrelated to changing the current row
number.
Therefore getRow() should work for FORWARD_ONLY ResultSets, but Derby currently
fails on this.
I haven't looked at what " theResults.getRowNumber() " does, but I hope the fix
for this bug is as simple as removing the call to checkScrollCursor;
> Derby EmbedResultSet does not conform to JDBC API for getRow()
> --------------------------------------------------------------
>
> Key: DERBY-4251
> URL: https://issues.apache.org/jira/browse/DERBY-4251
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.4.2.0, 10.5.1.1
> Environment: Windows XP, and Java 6 or Java 1.4.2
> Reporter: Andrew McRae
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> According to source of the Derby version I first found it in, and the version
> just released today, here is the offending code:
> https://svn.apache.org/repos/asf/db/derby/code/tags/10.5.1.1/java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
> {quote}
> public int getRow() throws SQLException {
> // getRow() is only allowed on scroll cursors
> checkScrollCursor("getRow()");
> /*
> * * We probably needn't bother getting the text of * the
> underlying
> * statement but it is better to be * consistent and we aren't
> * particularly worried * about performance of getRow().
> */
> return theResults.getRowNumber();
> }
> {quote}
> The comment and the check for scrollability is incorrect. The Javadoc comment
> for this getRow is a duplicate of the Sun JDK API for ResultSet.getRow(), and
> if the author had just written it according to their own javadoc there would
> be no problem.
> See spec here:
> http://java.sun.com/j2se/1.3/docs/api/java/sql/ResultSet.html#getRow()
> The Sun Javadoc does not spell out any exceptions to the required behaviour.
> getRow should always work regardless of whether the result set is scrollable
> because the issue of scrollability is whether the client can *reposition* the
> cursor to change the current row of the result set. Simply *reading* the
> current row number is different and unrelated to changing the current row
> number.
> Therefore getRow() should work for FORWARD_ONLY ResultSets, but Derby
> currently fails on this.
> Quite aside from the spec nonconformance, it's a bit annoying that my
> application has worked fine on Oracle, MS SQL, the JDBC-LDAP bridge driver,
> and even MS Access MDB files via the Sun JDBC-ODBC bridge driver, but then
> the Derby engine falls over just trying to run a simple Select statement on a
> non-updatable forward-only result set - the simplest kind of all!
> I haven't looked at what " theResults.getRowNumber() " does, but I hope the
> fix for this bug is as simple as removing the call to checkScrollCursor;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
