Derby
  1. Derby
  2. DERBY-1286

Fill in Clob methods required for JDBC3 compliance

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.3.1.4
    • Component/s: JDBC
    • Labels:
      None
    • Urgency:
      Normal

      Description

      Fill in Clob methods which we need to be JDBC3-compliant:

      • The following java.sql.CallableStatement methods:
      • getClob(int)
      • The following java.sql.ResultSet methods:
      • updateClob(int,java.sql.Clob)
      • updateClob(java.lang.String,java.sql.Clob)
      • The following java.sql.Clob methods:
      • setString(long,java.lang.String)
      • setString(long,java.lang.String,int,int)
      • setAsciiStream(long)
      • getCharacterStream(long,long)
      • setCharacterStream(long)
      • truncate(long)

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          Please see DERBY-1283 for the discussion of JDBC3 vs JDBC4 compliance and the question of whether compliance is a moving target.

          Show
          Rick Hillegas added a comment - Please see DERBY-1283 for the discussion of JDBC3 vs JDBC4 compliance and the question of whether compliance is a moving target.
          Hide
          Rick Hillegas added a comment -

          Added ResultSet.updateClob() to list of methods needing implementations.

          Show
          Rick Hillegas added a comment - Added ResultSet.updateClob() to list of methods needing implementations.
          Hide
          Daniel John Debrunner added a comment -

          Is there a good definition in the specification as to how the Clob.setXXX methods are defined to work? Section 16.3.3. of JDBC 3.0 has wording that is pretty vague. The javadoc for these methods doesn't help much either. (Similar concern for Blob.setXXX)

          Q1 - I can think of three possible implementations for the setXXX methods:
          A) Overwite any existing data from the passed in position
          B) Replace the data from passed in position onwards
          C) Insert the data into the value at the position

          For example, with an existing Clob with value "To be or not to be", and calling setString(7, "is all") I can see getting:

          A) "To be is all to be"
          B) "To be is all"
          C) "To be is allor not to be"

          From a quick check of the (ugly, see DERBY-684) client code, I think it implements B.

          Q2 - is that if I call setXXXStream() but never write to the stream, is the value modified?
          What if the stream is written to with 0 bytes/characters?
          If the defined behaviour above is B) then there's a case to be made that it should be truncated to length matching the passed in position.

          Q3 - setString returns the number of characters written, is that allowed to be different to the number of characters that are requested to be written? Like OutputStream.writr(byte[])?

          Sorry if these answers are obvious.

          BTW - there is a bug in the javadoc for Clob.truncate() that indicates for the parameter that the truncation is in bytes. The overview of the method indicates correctly it is in characters. This still seems to be an issue in JDBC 4.

          Show
          Daniel John Debrunner added a comment - Is there a good definition in the specification as to how the Clob.setXXX methods are defined to work? Section 16.3.3. of JDBC 3.0 has wording that is pretty vague. The javadoc for these methods doesn't help much either. (Similar concern for Blob.setXXX) Q1 - I can think of three possible implementations for the setXXX methods: A) Overwite any existing data from the passed in position B) Replace the data from passed in position onwards C) Insert the data into the value at the position For example, with an existing Clob with value "To be or not to be", and calling setString(7, "is all") I can see getting: A) "To be is all to be" B) "To be is all" C) "To be is allor not to be" From a quick check of the (ugly, see DERBY-684 ) client code, I think it implements B. Q2 - is that if I call setXXXStream() but never write to the stream, is the value modified? What if the stream is written to with 0 bytes/characters? If the defined behaviour above is B) then there's a case to be made that it should be truncated to length matching the passed in position. Q3 - setString returns the number of characters written, is that allowed to be different to the number of characters that are requested to be written? Like OutputStream.writr(byte[])? Sorry if these answers are obvious. BTW - there is a bug in the javadoc for Clob.truncate() that indicates for the parameter that the truncation is in bytes. The overview of the method indicates correctly it is in characters. This still seems to be an issue in JDBC 4.
          Show
          Kathey Marsden added a comment - removing from 10.2. see: http://www.nabble.com/10.2-High-Value-Fix-Candidates-and-Fix-Version-Adjustments-tf2007999.html
          Hide
          Kristian Waagan added a comment -

          Just want to point out that the method Clob.getCharacterStream(long,long) was added in JDBC4.

          Show
          Kristian Waagan added a comment - Just want to point out that the method Clob.getCharacterStream(long,long) was added in JDBC4.
          Hide
          Øystein Grøvlen added a comment -

          I changing this to resolved since all methods except the CallableStatement.getClob method has now been implemented. I will open another JIRA for this method. (It is of no use to implement this method before DERBY-2201 is fixed)

          Show
          Øystein Grøvlen added a comment - I changing this to resolved since all methods except the CallableStatement.getClob method has now been implemented. I will open another JIRA for this method. (It is of no use to implement this method before DERBY-2201 is fixed)

            People

            • Assignee:
              Unassigned
              Reporter:
              Rick Hillegas
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development