Derby
  1. Derby
  2. DERBY-1744

ResultSet.rowInserted(), rowUpdated() and rowDeleted() don't throw exception on read-only result sets

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: 10.0.2.1
    • Fix Version/s: None
    • Component/s: JDBC
    • Labels:
      None

      Description

      These methods should throw SQLException if concurrency is CONCUR_READ_ONLY. See http://download.java.net/jdk6/docs/api/java/sql/ResultSet.html:

      Throws:
      SQLException - if a database access error occurs; the result set concurrency is CONCUR_READ_ONLY or this method is called on a closed result set

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          6d 9h 48m 1 Knut Anders Hatlen 28/Aug/06 18:26
          Gavin made changes -
          Workflow jira [ 12382164 ] Default workflow, editable Closed status [ 12798105 ]
          Knut Anders Hatlen made changes -
          Resolution Invalid [ 6 ]
          Status Open [ 1 ] Closed [ 6 ]
          Hide
          Knut Anders Hatlen added a comment -

          Thanks to Dag and Lance for clearing this up. Closing the issue as invalid.

          Show
          Knut Anders Hatlen added a comment - Thanks to Dag and Lance for clearing this up. Closing the issue as invalid.
          Dag H. Wanvik made changes -
          Link This issue relates to DERBY-1769 [ DERBY-1769 ]
          Hide
          Dag H. Wanvik added a comment -

          I raised this with Lance, and the JDBC Expert Group has now added the
          "support optional" wording to rowUpdated and rowInserted, as well.

          I.e. there is no longer a requirement that we throw exceptions for
          rowXXX methods in the case of read-only RS. Since support is now marked
          as optional in the API, we should add a note in the docs on how Derby
          behaves wrt this. I will file a JIRA.

          The API change should become apparent at
          http://download.java.net/jdk6/docs/api/ as soon as the next build is
          available (rc-b98).

          Show
          Dag H. Wanvik added a comment - I raised this with Lance, and the JDBC Expert Group has now added the "support optional" wording to rowUpdated and rowInserted, as well. I.e. there is no longer a requirement that we throw exceptions for rowXXX methods in the case of read-only RS. Since support is now marked as optional in the API, we should add a note in the docs on how Derby behaves wrt this. I will file a JIRA. The API change should become apparent at http://download.java.net/jdk6/docs/api/ as soon as the next build is available (rc-b98).
          Hide
          Dag H. Wanvik added a comment -

          Thanks for your investigation, Knut Anders. I can confirm your
          findings. Meanwhile I checked the latest API I could find for Mustang
          (b97) and found that the wording for rowDeleted differs from the
          wording for rowUpdated (and rowInserted) in one substantial respect:

          (quote)

          > rowDeleted
          >
          > boolean rowDeleted() throws SQLException
          >
          > Retrieves whether a row has been deleted. A deleted row may leave
          > a visible "hole" in a result set. This method can be used to
          > detect holes in a result set. The value returned depends on
          > whether or not this ResultSet object can detect deletions.
          >
          > Note: Support for the rowDeleted method is optional with a result
          > set concurrency of CONCUR_READ_ONLY
          **************************************

          >
          > Returns: true if the current row is detected to have been deleted
          > by the owner or another; false otherwise
          >
          > Throws:
          > SQLException - if a database access error occurs or this
          > method is called on a closed result set
          >
          > SQLFeatureNotSupportedException - if the JDBC driver does not
          > support this method

                        • Note: no requirement that we throw exception if read-only result

          > set. The wording for rowUpdated is different:

          In contrast, the wording for rowUpdated is:

          > boolean rowUpdated() throws SQLException
          >
          > Retrieves whether the current row has been updated. The value
          > returned depends on whether or not the result set can detect
          > updates.
          >
          > Returns:
          >
          > true if the current row is detected to have been visibly
          > updated by the owner or another; false otherwise
          >
          > Throws:
          >
          > SQLException - if a database access error occurs; the result
          > set concurrency is CONCUR_READ_ONLY or this method is called
          > on a closed result set
          *******************************
          In this case there is throw requirement.

          >
          > SQLFeatureNotSupportedException - if the JDBC driver does not
          > support this method

          In Derby, we currently allow these method calls on read-only result
          sets (which was OK with JDBC 3, which specifies SQLException only if
          "a data base errros occurs"). Now, the wording has been changed for
          both rowUpdated and rowDeleted in JDBC4 (b97), but they seem
          inconsistent. Is it really the intention that these two should have a
          different behavior on read-only result sets?

          I would prefer it to be allowed (i.e. "support optional") for
          rowUpdated also (and rowInserted), since that allows both methods to
          work as expected for updates via cursor, which we do allow in Derby if
          the underlying result set is updatable (implementation cursor <-> RS
          equivalence), even if RS is read-only.

          Another data point: Metadata calls (e.g. updatesAreDetected(int type))
          do no differentiate between read-only and updatable result sets. Not
          sure if that plays into the equation here, but it seems to me that
          since they do not differentiate, and if they do return "true" for a
          result set type, then there should be no requirement that we throw an
          exception.

          I'd like to get this clarified before with proceed with this issue,
          I'll ping Lance. Hopefully we can still be allowed to not throw
          exceptions for rowUpdated, rowInserted.

          Show
          Dag H. Wanvik added a comment - Thanks for your investigation, Knut Anders. I can confirm your findings. Meanwhile I checked the latest API I could find for Mustang (b97) and found that the wording for rowDeleted differs from the wording for rowUpdated (and rowInserted) in one substantial respect: (quote) > rowDeleted > > boolean rowDeleted() throws SQLException > > Retrieves whether a row has been deleted. A deleted row may leave > a visible "hole" in a result set. This method can be used to > detect holes in a result set. The value returned depends on > whether or not this ResultSet object can detect deletions. > > Note: Support for the rowDeleted method is optional with a result > set concurrency of CONCUR_READ_ONLY ************************************** > > Returns: true if the current row is detected to have been deleted > by the owner or another; false otherwise > > Throws: > SQLException - if a database access error occurs or this > method is called on a closed result set > > SQLFeatureNotSupportedException - if the JDBC driver does not > support this method Note: no requirement that we throw exception if read-only result > set. The wording for rowUpdated is different: In contrast, the wording for rowUpdated is: > boolean rowUpdated() throws SQLException > > Retrieves whether the current row has been updated. The value > returned depends on whether or not the result set can detect > updates. > > Returns: > > true if the current row is detected to have been visibly > updated by the owner or another; false otherwise > > Throws: > > SQLException - if a database access error occurs; the result > set concurrency is CONCUR_READ_ONLY or this method is called > on a closed result set ******************************* In this case there is throw requirement. > > SQLFeatureNotSupportedException - if the JDBC driver does not > support this method In Derby, we currently allow these method calls on read-only result sets (which was OK with JDBC 3, which specifies SQLException only if "a data base errros occurs"). Now, the wording has been changed for both rowUpdated and rowDeleted in JDBC4 (b97), but they seem inconsistent. Is it really the intention that these two should have a different behavior on read-only result sets? I would prefer it to be allowed (i.e. "support optional") for rowUpdated also (and rowInserted), since that allows both methods to work as expected for updates via cursor, which we do allow in Derby if the underlying result set is updatable (implementation cursor <-> RS equivalence), even if RS is read-only. Another data point: Metadata calls (e.g. updatesAreDetected(int type)) do no differentiate between read-only and updatable result sets. Not sure if that plays into the equation here, but it seems to me that since they do not differentiate, and if they do return "true" for a result set type, then there should be no requirement that we throw an exception. I'd like to get this clarified before with proceed with this issue, I'll ping Lance. Hopefully we can still be allowed to not throw exceptions for rowUpdated, rowInserted.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks for your comments, Dag. There already are similar changes in these methods from 10.1 to 10.2. For instance, DERBY-1323 changed the behaviour of these methods, and it has both the Existing Application Impact and the Release Note Needed flags. Standards compliace is a good thing, so I would say we should change it and have a release note that mentions these changes and the changes in DERBY-1323 together.

          One problem I have come across, is that the network server calls these methods on read-only result sets. Because of the way Derby implements updatable result sets and positioned updates, it is possible that the methods return true on a read-only result set with an updatable cursor. Since the spec says they should raise an error when the result set is true, these methods cannot be used to check if a row in read-only result set has been changed with a positioned update. I haven't found a way to work around this yet.

          Show
          Knut Anders Hatlen added a comment - Thanks for your comments, Dag. There already are similar changes in these methods from 10.1 to 10.2. For instance, DERBY-1323 changed the behaviour of these methods, and it has both the Existing Application Impact and the Release Note Needed flags. Standards compliace is a good thing, so I would say we should change it and have a release note that mentions these changes and the changes in DERBY-1323 together. One problem I have come across, is that the network server calls these methods on read-only result sets. Because of the way Derby implements updatable result sets and positioned updates, it is possible that the methods return true on a read-only result set with an updatable cursor. Since the spec says they should raise an error when the result set is true, these methods cannot be used to check if a row in read-only result set has been changed with a positioned update. I haven't found a way to work around this yet.
          Hide
          Dag H. Wanvik added a comment -

          We noticed this in the SUR work, but chose not to change it for fear
          of affecting exisiting apps. Do we want to change it?

          Show
          Dag H. Wanvik added a comment - We noticed this in the SUR work, but chose not to change it for fear of affecting exisiting apps. Do we want to change it?
          Knut Anders Hatlen made changes -
          Field Original Value New Value
          Assignee Knut Anders Hatlen [ knutanders ]
          Knut Anders Hatlen created issue -

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development