Derby
  1. Derby
  2. DERBY-2652

Clob.setCharacterStream differs between embedded and client driver

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.2.2.0, 10.3.1.4
    • Fix Version/s: 10.3.1.4
    • Component/s: JDBC
    • Labels:
      None

      Description

      Clob.setCharacterStream behaves differently depending on whether you use the embedded or the client driver.
      Sample output from the repro:

      (embedded) Initial : 123456789
      (embedded) After : 12__56789

      (client) Initial : 123456789
      (client) After : 12__

      As can be seen, the client driver truncates the Clob value when it writes to it, whereas the embedded driver does not and instead replaces existing characters with those written to the character stream.

      (BTW: I know the title is not perfectly accurate, but it got so long when explaining that it is when you actually write to the stream returned by Clob.setCharacterStream the result differs.)

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          Attached repro 'ClobSetCharacterStreamTest.java'.

          Show
          Kristian Waagan added a comment - Attached repro 'ClobSetCharacterStreamTest.java'.
          Hide
          Kristian Waagan added a comment -

          Clob.setAsciiStream has the same problem.

          The existing repro can be used by replacing setCharacterStream with setAsciiStream, Writer with OutputStream and "_" with 0x5F (or use a char).

          Now, what is the correct behavior?

          Show
          Kristian Waagan added a comment - Clob.setAsciiStream has the same problem. The existing repro can be used by replacing setCharacterStream with setAsciiStream, Writer with OutputStream and "_" with 0x5F (or use a char). Now, what is the correct behavior?
          Hide
          Øystein Grøvlen added a comment -

          I would assume the behavior should be the same as for Clob.setString. This isssue was raised in DERBY-1286 and Lance presented the opinion of the expert group in the following thread:
          http://www.nabble.com/-jira--Created%3A-%28DERBY-1286%29-Fill-in-Clob-methods-required-for-JDBC3-compliance-tf1553591.html#a4549524
          This discussion indicates that the embedded has the right behavior. (That is also similar to the current client behavior for Blobs.)

          When using locators the client will forward the operation to the server. Hence, this difference should disappear when locators are enabled for Clobs.


          Øystein

          Show
          Øystein Grøvlen added a comment - I would assume the behavior should be the same as for Clob.setString. This isssue was raised in DERBY-1286 and Lance presented the opinion of the expert group in the following thread: http://www.nabble.com/-jira--Created%3A-%28DERBY-1286%29-Fill-in-Clob-methods-required-for-JDBC3-compliance-tf1553591.html#a4549524 This discussion indicates that the embedded has the right behavior. (That is also similar to the current client behavior for Blobs.) When using locators the client will forward the operation to the server. Hence, this difference should disappear when locators are enabled for Clobs. – Øystein
          Hide
          Kristian Waagan added a comment -

          Shall we do anything about this for 10.2, or is that too late anyway? (introducing "incompatible" behavior between 10.2 releases)
          If so, I will close this issue.

          Show
          Kristian Waagan added a comment - Shall we do anything about this for 10.2, or is that too late anyway? (introducing "incompatible" behavior between 10.2 releases) If so, I will close this issue.
          Hide
          Øystein Grøvlen added a comment -

          I do not think we should change the behavior between 10.2 releases. Also, for 10.2 we would have to come up with a different solution that is not based on locators.

          Show
          Øystein Grøvlen added a comment - I do not think we should change the behavior between 10.2 releases. Also, for 10.2 we would have to come up with a different solution that is not based on locators.
          Hide
          Kristian Waagan added a comment -

          I agree with Øystein and I close the issue as fixed.
          Note that the difference in behavior is still there for 10.2, but it has been fixed for 10.3 with the change to locator based LOBs.

          Show
          Kristian Waagan added a comment - I agree with Øystein and I close the issue as fixed. Note that the difference in behavior is still there for 10.2, but it has been fixed for 10.3 with the change to locator based LOBs.

            People

            • Assignee:
              Unassigned
              Reporter:
              Kristian Waagan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development