Andreas Korneliussen wrote:
Lance J. Andersen wrote:
Here is the description of String.subString()


      substring

public String <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html> *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|.

    Examples:

 "hamburger".substring(4, 8) returns "urge"
 "smiles".substring(1, 5) returns "mile"
    *Parameters:*
        |beginIndex| - the beginning index, inclusive.
        |endIndex| - the ending index, exclusive.     *Returns:*
        the specified substring.     *Throws:*
        |IndexOutOfBoundsException
<http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IndexOutOfBoundsException.html>|
        - if the |beginIndex| is negative, or |endIndex| is larger than
        the length of this |String| object, or |beginIndex| is larger
        than |endIndex|.



So this indicates to me that a SQLException is what is to be expected in this case in the case of Kathey's example.


I do not agree that a SQLException is expected.
Clob.getSubString(..) is 1 based, String.substring(..) is 0 based.
So Clob.getSubString(1, 0) maps down to String.substring(0, 0), which returns the empty string. (And yes i do not like the fact that the indexing is different then the JDK either for these methods...)
Yes but forget the getSubString(1,0) scenario getSubString(4,3) would also apply to this case as well.

The issue as i said in my previous response to Thomas, is what does the EG want to document at this time given the behavior has been undefined since JDBC 2.0 and there are multiple JDBC drivers for some of the backends that Thomas has listed and without explicitly testing all of them, i certainly cannot speak to whether they all behave consistently. If they do, great it is easier to address. If they do not, then it boils down to whether they can agree on a behavior or it gets documented as an implementation dependent issue.

"".substring(0,0) returns the empty string ("").

Andreas


Regards
Lance


Craig L Russell wrote:

Hi Lance,

Now that Kathey has kicked it back to you and me, how about updating the to-be-released JDBC 4 to point out that a length of zero for the getSubString is valid?

String getSubString(long pos,
                    int length)
                    throws SQLException
Retrieves a copy of the specified substring in the CLOB value designated by this Clob object. The substring begins at position pos and has up to length consecutive characters.

Parameters:
pos - the first character of the substring to be extracted. The first character is at position 1.
length - the number of consecutive characters to be copied

We might simply add to this description.

length - the number of consecutive characters to be copied; 0 is a valid value

We have a similar case with Blob byte[ ] getBytes().

Can you run this past the expert group for a quick consensus?

Thanks,

Craig

On Jul 14, 2006, at 11:13 PM, Kathey Marsden wrote:

Craig L Russell wrote:

You can always work around odd code on the other side of an incompletely defined interface. But you probably have code on the Derby side that also checks for the clob.length() == 0 and take some extraordinary action.

So much easier for neither side to check for zero length and let the natural boundary condition happen.

I am happy that you agree that the original DDLUtils code was perfectly reasonable at not as Lance described it. I will exit this issue now and allow you, Lance, or someone else with interest determine the correct behavior, check it with Derby and file a Derby bug if needed.

Kathey


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!


Reply via email to