db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1312) refreshRow behavior not the same in Derby client and embedded drivers
Date Tue, 19 Sep 2006 15:25:22 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1312?page=all ]

Rick Hillegas updated DERBY-1312:
---------------------------------

    Fix Version/s: 10.2.2.0
                       (was: 10.2.1.0)

Moving to 10.2.2.0.

> 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
>          Issue Type: Improvement
>          Components: JDBC, Network Client
>    Affects Versions: 10.1.1.0, 10.2.1.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.2.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