Re: [jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network

["Lance J. Andersen" <La...@Sun.COM>]

Craig Russell (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424673 ] 
>             
> Craig Russell commented on DERBY-1516:
> --------------------------------------
>
> Including the discussion from the alias referenced immediately above:
>
>   
>>> One interesting test with 0 length is the case for getSubString(1,0) 
>>> for a zero length lob. 
>>> Should it throw an exception or return a zero length string? 
>>>       
>
>   
>> The API working doesn't give much help to resolve this; the wording for the exception in JDK 1.6 is 
>>     
>
>   
>> Throws: 
>>    SQLException - if there is an error accessing the CLOB value 
>>     
>
>   
>> which I guess is equivalent to YMMV... A case for Lance? 
>>     
>
>   
>> Even if this case is allowed, should it make a difference if position is > (length+1), e.g. getSubString(2,0) for an empty CLOB? 
>>     
>
> Lance has not replied to a request to update the wording, and I think time is running out on this to be added to the specification in progress.
>   
Actually that is not true, i did reply if you check the archives, but 
this issue is not on my radar as i have other issues that are of higher 
importance right now given my short window of opportunity due to the 
Mustang schedule.

> The jdbc spec has followed the java.lang.String spec pretty closely, modulo 1-origin vs. 0-origin indexing. The String spec allows accessing substrings of a 0-length string, as follows:
>
> public String substring(int beginIndex,
>                         int endIndex)
> Returns a new string that is a substring of this string. The substring begins at the specified beginIndex and extends to the character at index endIndex - 1. Thus the length of the substring is endIndex-beginIndex...
> IndexOutOfBoundsException - if the beginIndex is negative, or endIndex is larger than the length of this String object, or beginIndex is larger than endIndex.
>
> For a zero-length String:
> 1. endIndex must be 0 or else endIndex would be larger than the length of the String;
> 2. beginIndex must be 0 or else beginIndex would be larger than endIndex.
>
> Translating this to jdbc, for a zero-length Clob:
> 1. position must be 1;
> 2. length must be 0.
>
> I agree we should add positive test cases to extract a zero-length substring from a Clob and Blob. 
>
> I propose adding to clobTest2 and blobTest2 a test like: 
> blobclob4BLOB.printInterval(clob, 1, 0, 7, i, clobLength) // zero length
> blobclob4BLOB.printInterval(blob, 1, 0, 7, i, blobLength) // zero length
>
>
>   
>> Inconsistent behavior for getBytes and getSubString for embedded versus network
>> -------------------------------------------------------------------------------
>>
>>                 Key: DERBY-1516
>>                 URL: http://issues.apache.org/jira/browse/DERBY-1516
>>             Project: Derby
>>          Issue Type: Bug
>>          Components: JDBC
>>            Reporter: Craig Russell
>>         Assigned To: Craig Russell
>>            Priority: Minor
>>         Attachments: DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch
>>
>>
>> org.apache.derby.client.am.Clob.getSubString(pos, length) and org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for less than zero. 
>>             if ((pos <= 0) || (length < 0)) {
>>                 throw new SqlException(agent_.logWriter_, "Invalid position " + pos + " or length " + length);
>> But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less than or equal to zero.
>>        if (length <= 0)
>>             throw Util.generateCsSQLException(
>>                 SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
>> The specification does not disallow length of zero, so zero length should be allowed. I believe that the implementation in org.apache.derby.client.am is correct, and the implementation in org.apache.derby.impl.jdbc is incorrect. 
>>     
>
>