Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-1312

refreshRow behavior not the same in Derby client and embedded drivers

    XMLWordPrintableJSON

    Details

    • 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
    • Fix Version/s: None
    • Component/s: JDBC, Network Client
    • Urgency:
      Low
    • Bug behavior facts:
      Embedded/Client difference

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                dagw Dag H. Wanvik
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: