[DERBY-1312] refreshRow behavior not the same in Derby client and embedded drivers

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6
• Component/s: JDBC, Network Client
• Labels: derby_triage10_11
• Urgency: Low
• Bug behavior facts: Embedded/Client difference
• Assignee: Unassigned
• Reporter: Dag H. Wanvik
• Created: 10/May/06 06:43
• Updated: 18/Jul/13 17:34

Description

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.

Issue Links

• is part of: DERBY-310 Document and/or change Derby client code to match behavior with Embedded driver where possible.