db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1286) Fill in Clob methods required for JDBC3 compliance
Date Wed, 24 May 2006 21:20:33 GMT
This is what we discussed in the EG and agreed to in this regards

consider a Clob, aClob,  containing the following value for each
setString() invocation below.

ABCDEFG


        *A. aClob.setString(2, "XX") *

Result:   AXXDEFG


        *B. aClob.setString(1, "XX") *

Result:  XXCDEFG
 


        *C. aClob.setString(8, "XX") *


Result:  ABCDEFGXX


        *D. aClob.setString(7, "XX") *


Result:  ABCDEFXX


        *E. aClob.setString(9, "XX)*

Where we are:

We agreed that we all felt the correct behavior is to return a 
SQLException.



Daniel John Debrunner (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1286?page=comments#action_12378987 ]

>
> Daniel John Debrunner commented on DERBY-1286:
> ----------------------------------------------
>
> 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.
>   
If you do not write, there are not changes, the offset is just a 
positioning.
> 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[])?
>   
vendors did not have an easy answer on when/if the number written/would 
differ, so i would say this is implementations specific.
> 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.
>   
fixed thanks
>   
>> Fill in Clob methods required for JDBC3 compliance
>> --------------------------------------------------
>>
>>          Key: DERBY-1286
>>          URL: http://issues.apache.org/jira/browse/DERBY-1286
>>      Project: Derby
>>         Type: Improvement
>>     
>
>   
>>   Components: JDBC
>>     Versions: 10.2.0.0
>>     Reporter: Rick Hillegas
>>      Fix For: 10.2.0.0
>>     
>
>   
>> 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)
>>     
>
>   

Mime
View raw message