[jira] Commented: (DERBY-1286) Fill in Clob methods required for JDBC3 compliance

2006-07-31 Thread Kristian Waagan (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1286?page=comments#action_12424527 ] 

Kristian Waagan commented on DERBY-1286:


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



 Fill in Clob methods required for JDBC3 compliance
 --

 Key: DERBY-1286
 URL: http://issues.apache.org/jira/browse/DERBY-1286
 Project: Derby
  Issue Type: Improvement
  Components: JDBC
Affects Versions: 10.2.0.0
Reporter: Rick Hillegas

 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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: [jira] Commented: (DERBY-1286) Fill in Clob methods required for JDBC3 compliance

2006-05-30 Thread Kristian Waagan

Lance J. Andersen wrote:

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.


I tried doing this in Derby, and I do see the behavior Dan pointed out 
in his mail (see below).




ABCDEFG


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

Result:   AXXDEFG


Derby: AXX




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

Result:  XXCDEFG


Derby: XX

 



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


Result:  ABCDEFGXX


Derby: ABCDEFGXX




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


Result:  ABCDEFXX


Derby: ABCDEFXX




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

Where we are:

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


Derby: SQLException

So, Derby truncates the clob after the last inserted character (if there 
is more left of the original clob).

Has a Jira been entered for this?
If not, should we declare this a bug?

I also took a quick look at Blob.setBytes in the client driver. I think 
it has the same behavior as Clob.setString. Is this a bug as well?




--
Kristian





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)



  




Re: [jira] Commented: (DERBY-1286) Fill in Clob methods required for JDBC3 compliance

2006-05-25 Thread Andrew McIntyre

On 5/24/06, Lance J. Andersen [EMAIL PROTECTED] wrote:


 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


The fact that these are one-indexed instead of zero-indexed seems like
a really good thing to mention in the javadoc for these methods.

my $.02,
andrew


Re: [jira] Commented: (DERBY-1286) Fill in Clob methods required for JDBC3 compliance

2006-05-25 Thread Lance J. Andersen

this is in the javadocs for jdbc 4.0

Andrew McIntyre wrote:

On 5/24/06, Lance J. Andersen [EMAIL PROTECTED] wrote:


 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


The fact that these are one-indexed instead of zero-indexed seems like
a really good thing to mention in the javadoc for these methods.

my $.02,
andrew


[jira] Commented: (DERBY-1286) Fill in Clob methods required for JDBC3 compliance

2006-05-10 Thread Daniel John Debrunner (JIRA)
[ 
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.

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.

 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)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira