db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1312) refreshRow behavior not the same in Derby client and embedded drivers
Date Tue, 09 May 2006 23:52:05 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1312?page=comments#action_12378784 ] 

Dag H. Wanvik commented on DERBY-1312:
--------------------------------------

The reference manual does not have refreshRow listed in the table
of supported methods from the ResultSet interface, so the
embedded behavior is probably what we want.

> refreshRow behavior not the same in Derby client and embedded drivers
> ---------------------------------------------------------------------
>
>          Key: DERBY-1312
>          URL: http://issues.apache.org/jira/browse/DERBY-1312
>      Project: Derby
>         Type: Improvement

>   Components: JDBC, Network Client
>     Versions: 10.1.1.0, 10.2.0.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2,
10.1.2.3, 10.1.2.4
>     Reporter: Dag H. Wanvik
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> In the embedded client, ResultSet#refreshRow throws a not implemented
> exception.  In the client driver, it is implemented as a no-op (*) for
> the updatable result set types we support, although it has some cruft
> for sensitive result sets - from a previous life?
> (*) Checks are performed to see if the method is callable given the
> state of the result set, but no actual refresh is attempted. This is
> correct for scroll insensitive result sets, btw.
> The client implementation is wrong in another respect: (Quote from
> JDBC 3.0 API javadoc):
> "If refreshRow is called after calling an updater method, but before
> calling the method updateRow, then the updates made to the row are
> lost."
> As far as I can see, since this is implemented as a no-op, this
> implicit update canceling does not happen.
> I think we should reconcile the driver behaviors, probably by having
> the client throw a not implemented exception as well.  It is not
> really needed for scroll insensitive result sets.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message