[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[ http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12427263 ] David Van Couvering commented on DERBY-1516: Hi, Craig. I merged your patch into my sandbox and ran derbyall, and I'm sorry to say I had a test failure. derbynetmats/DerbyNet/jdbcapi/blobclob4BLOB is the test, I think you just didn't run this under the DerbyNet framework (which is the IBM JDBC driver). Here are the diffs. If you think these look good I can go ahead and update the master file. However, I am concerned about the open result set error at the end of the diff... * Diff file derbyall/derbynetmats/DerbyNet/jdbcapi/blobclob4BLOB.diff *** Start: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-09 18:04:28 *** 90d89 CLOB getSubString 1 0 92,93d90 CLOB FAIL - NO ERROR ON getSubString POS TOO LARGE 1 0 CLOB getSubString 1 0 95 del CLOB FAIL - NO ERROR ON getSubString POS TOO LARGE 1 0 95a92,93 1(7) (len 0) 1(8) (len 0) 107a106,107 2(7) (len 0) 2(8) (len 0) 119a120,121 3(7) (len 0) 3(8) (len 0) 132a135,136 4(7) (len 0) 4(8) (len 0) 144a149,150 5(7) (len 0) 5(8) (len 0) 154 del 6(7) 154a160,162 6(7) (len 0) 6(8) (len 0) 6(9) 166d173 CLOB getSubString 1 0 168,169d174 CLOB FAIL - NO ERROR ON getSubString POS TOO LARGE 1 0 CLOB getSubString 1 0 171 del CLOB FAIL - NO ERROR ON getSubString POS TOO LARGE 1 0 171a176,177 7(7) (len 0) 7(8) (len 0) 183 del 8(7) 183a189,191 8(7) (len 0) 8(8) (len 0) 8(9) 194 del 9(7) 194a202,204 9(7) (len 0) 9(8) (len 0) 9(9) 456a467 java.lang.StringIndexOutOfBoundsException: String index out of range: -1 460 del negative tests for clob.getSubstring won't run for network server until 5243 is fixed 460a471,475 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 577 del Known JCC Bug 5914 577a592 FAIL: Caught exception java.lang.NegativeArraySizeException 579 del Known JCC Bug 5914 579a594 FAIL: Caught exception java.lang.NegativeArraySizeException 581 del Known JCC Bug 5914 581a596 FAIL: Caught exception java.lang.NegativeArraySizeException 583 del Known JCC Bug 5914 583a598 FAIL: Caught exception java.lang.NegativeArraySizeException 585 del Known JCC Bug 5914 586 del testing Blob.getBytes() with pos 1 0 586a600 FAIL: Caught exception java.lang.NegativeArraySizeException 588,589d601 FAIL testing Blob.getBytes() with pos 1 0 testing Blob.getBytes() with pos 1 0 591 del FAIL testing Blob.getBytes() with pos 1 0 591a603,604 1(7) 1(8) 593 del Known JCC Bug 5914 593a606 FAIL: Caught exception java.lang.NegativeArraySizeException 595 del Known JCC Bug 5914 595a608 FAIL: Caught exception java.lang.NegativeArraySizeException 597 del Known JCC Bug 5914 597a610 FAIL: Caught exception java.lang.NegativeArraySizeException 599 del Known JCC Bug 5914 599a612 FAIL: Caught exception java.lang.NegativeArraySizeException 601 del Known JCC Bug 5914 601a614 FAIL: Caught exception java.lang.NegativeArraySizeException 603a617,618 2(7) 2(8) 605 del Known JCC Bug 5914 605a620 FAIL: Caught exception java.lang.NegativeArraySizeException 607 del Known JCC Bug 5914 607a622 FAIL: Caught exception java.lang.NegativeArraySizeException 609 del Known JCC Bug 5914 609a624 FAIL: Caught exception java.lang.NegativeArraySizeException 611 del Known JCC Bug 5914 611a626 FAIL: Caught exception java.lang.NegativeArraySizeException 613 del Known JCC Bug 5914 613a628 FAIL: Caught exception java.lang.NegativeArraySizeException 615a631,632 3(7) 3(8) 617 del Known JCC Bug 5914 617a634 FAIL: Caught exception java.lang.NegativeArraySizeException 619 del Known JCC Bug 5914 619a636 FAIL: Caught exception java.lang.NegativeArraySizeException 621 del Known JCC Bug 5914 621a638 FAIL: Caught exception java.lang.NegativeArraySizeException 623 del Known JCC Bug 5914 623a640 FAIL: Caught exception java.lang.NegativeArraySizeException 625 del Known JCC Bug 5914 625a642 FAIL: Caught exception java.lang.NegativeArraySizeException 628a646,647 4(7) 4(8) 630 del Known JCC Bug 5914 630a649 FAIL: Caught exception java.lang.NegativeArraySizeException 632 del Known JCC Bug 5914 632a651 FAIL: Caught exception java.lang.NegativeArraySizeException 634 del Known JCC Bug 5914 634a653 FAIL: Caught exception java.lang.NegativeArraySizeException 636 del Known JCC Bug 5914 636a655 FAIL: Caught exception java.lang.NegativeArraySizeException 638 del Known JCC Bug 5914 638a657 FAIL: Caught exception java.lang.NegativeArraySizeException 640a660,661 5(7) 5(8) 650a672,673 6(8) 6(9) 653 del Known JCC Bug 5914 653a676 FAIL: Caught exception java.lang.NegativeArraySizeException 655 del
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12427294 ]
Craig Russell commented on DERBY-1516:
--
Hi David,
From my comments 31-Jul-2006:
I did not update master/DerbyNet/blobclob4BLOB.out canon because this canon
seems out of date wrt the code. If this is incorrect, please let me know.
I recommend checking in the new DerbyNet canon for the blobclob4BLOB output.
The differences in the DerbyNet canon are expected due to the additional tests
that I wrote. The unexpected exception in DerbyNet is expected in this
scenario due to the blobTest6 stimulating the DerbyNet driver to throw an
exception that is not a SQLException. Once the driver is fixed to properly
handle boundary errors (length 0; pos lob.length + 1; etc.), this
unexpected exception will go away.
There is a general issue in many of the tests that I looked at, that result
sets, statements, and connections are not closed in a finally block but are in
the main line code. So unexpected exceptions in general will cause subsequent
tests to behave unpredictably. But it's not specific to this issue.
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,
DERBY-1516.patch, 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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12427062 ]
David Van Couvering commented on DERBY-1516:
I'm working on comitting this patch
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,
DERBY-1516.patch, 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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426525 ]
Kathey Marsden commented on DERBY-1516:
---
Thanks Craig for the change, adding the test cases, and making sure client and
embedded have the same behavior. My only comment is that it would be be
good to first check in the reformatting changes for the test and keep just the
substantive code changes in issue commit.. I know the current situation with
DERBY-1363 is pretty intolerable, but it is better to keep code formatting
changes, when necessary, separate from the actual code changes.
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426621 ]
Daniel John Debrunner commented on DERBY-1516:
--
Since this has been a tricky area to get correct, it seems that adding Javadoc
comments to the methods your are modifying in the Derby implementations of Clob
Blob would add great value. Otherwise a few months from now someone may
change the code again thinking it is wrong (especially since the code no longer
matches the javadoc).
In Derby's JDBC implementation notes this comment exists for getSubString
http://db.apache.org/derby/papers/JDBCImplementation.html#getSubString%28int+pos%2C+int+length%29
If the pos (position) argument is greater than the length of the CLOB then an
exception is thrown. This matches the semantics of the SQL SUBSTR function.
Does that need to be corrected, do we have an issue because the new code will
not match SQL SUBSTR?
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426647 ]
Craig Russell commented on DERBY-1516:
--
Dan observes:
Since this has been a tricky area to get correct, it seems that adding
Javadoc comments to the methods your are modifying in the Derby
implementations of Clob Blob would add great value. Otherwise a few months
from now someone may change the code again thinking it is wrong (especially
since the code no longer matches the javadoc).
Could you please be a bit more specific, so I can do this in one pass? Which
parts of the code do you want to be better commented; e.g. just the parts I
modified, or the entire method?
In Derby's JDBC implementation notes this comment exists for getSubString
http://db.apache.org/derby/papers/JDBCImplementation.html#getSubString%28int+pos%2C+int+length%29
If the pos (position) argument is greater than the length of the CLOB then an
exception is thrown. This matches the semantics of the SQL SUBSTR function.
Does that need to be corrected, do we have an issue because the new code will
not match SQL SUBSTR?
Yes, that needs to be corrected, and I propose:
If the pos (position) argument is greater than the length + 1 of the CLOB then
an exception is thrown. This matches the semantics of the
java.lang.String.subString(int beginIndex, int endIndex) method.
A similar change is needed for Blob.getBytes
If the pos (position) argument is greater than the length of the BLOB then an
exception is thrown. This matches the semantics of the SQL SUBSTR function.
I propose:
If the pos (position) argument is greater than the length + 1 of the BLOB then
an exception is thrown. This matches the semantics of the
java.lang.System.arraycopy method.
I don't think that matching SQL semantics is as important as matching java
language semantics. After all, this API is a java language API.
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426674 ]
Craig Russell commented on DERBY-1516:
--
Here's a proposed javadoc comment for EmbedClob.getSubString:
* Valid pos values require that 0 pos clob.length + 1.
* Valid length values require that 0 = length = clob.length.
If this looks ok, I can update the javadoc for the other implementation classes.
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426687 ]
Daniel John Debrunner commented on DERBY-1516:
--
I mean comments clarifying the length position arguments passed in and the
valid ranges etc. Though while you were in there you could see if the
description was correct, e.g. EmbedClob.getSubString() says:
NOTE: return the empty string if pos is too large
which I don't think is true before or after your changes.
I think there's a strong case for matching the SQL semantics rather than the
Java semantics. One data point is that the value offsets are 1-based
matching SQL, not 0-based matching String. This is the offset into a class that
represents a SQL value, not a Java value.
The other data point is the new range for the position argument looks very
strange:
If the pos (position) argument is greater than the length + 1 of the BLOB then
an exception is thrown.
Why length +1, why not length?
Also that JDBC document already has clarified the behvaiour, why is it changing?
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426707 ]
Craig Russell commented on DERBY-1516:
--
Hi Dan,
Thanks for your comments.
I mean comments clarifying the length position arguments passed in and the
valid ranges etc. Though while you were in there you could see if the
description was correct, e.g. EmbedClob.getSubString() says:
NOTE: return the empty string if pos is too large
which I don't think is true before or after your changes.
I think I understand your comments and will try to update the comments to
reflect reality.
Why length +1, why not length?
If 0 pos = length, then there is no way to get any bytes (even zero bytes)
from a 0-length blob. And I don't believe that this is the intent. Nor is it
consistent with what other vendors have implemented.
There is no loss of functionality in the length + 1 behavior. If your
position is length + 1, then you can only get zero-length results from it. And
this is exactly the case of a zero-length Lob.
The title of this issue is inconsistent behavior for embedded versus network.
So something's gotta give. And after looking at it in detail, I'm convinced
that the right behavior is to be consistent with regard to getBytes and
getSubString; with regard to zero-length and non-zero-length Lobs; and with
regard to embedded versus network. And this patch does it.
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426714 ]
Daniel John Debrunner commented on DERBY-1516:
--
thanks Craig, that's good reasoning, and the type of useful information I would
like to see in the javadoc for these methods (using character for Clob and
bytes for Blob though). I think that's much clearer than trying to equate to
the behvaiour of String.substring.
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12426397 ]
Craig Russell commented on DERBY-1516:
--
I have run derby-all with these changes, and no errors were reported.
Any other comments before I check this in?
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12425568 ]
Dag H. Wanvik commented on DERBY-1516:
--
If you are modelling this on the java.lang.String modulo indexing, it
seems to me that this is slightly wrong:
The position must be between 1 and the last position of the Lob.
I think it should be
The position must be between 1 and the last position + 1 of the Lob,
cf. this example which does not throw exceptions. In the substring of
t2, the position is *one past* the final position of the string, final
position being 0.
String t1 = ;
String t2 = a;
String t3;
try {
System.out.println(t1.substring(0,0) = ' +
t1.substring(0,0) +
');
} catch (IndexOutOfBoundsException e) {
System.out.println(t1.substring(0,0) throws);
}
try {
System.out.println(t2.substring(1,1) = ' +
t2.substring(1,1) +
');
} catch (IndexOutOfBoundsException e) {
System.out.println(t2.substring(1,1) throws);
}
}
that is, you can always request an empty string from the position
*immediately after* the last byte, but not further out. This would
remove the asymmetry you have in the code, too:
if (this.length() == 0) {
if (pos 1) {
throw new SqlException(agent_.logWriter_,
new ClientMessageId(SQLState.BLOB_POSITION_TOO_LARGE),
new Long(pos));
}
} else { // this.length() 0
if (pos this.length()) {
throw new SqlException(agent_.logWriter_,
new ClientMessageId(SQLState.BLOB_POSITION_TOO_LARGE),
new Long(pos));
}
}
would reduce to:
if (pos this.length() + 1) {
throw new SqlException(agent_.logWriter_,
new ClientMessageId(SQLState.BLOB_POSITION_TOO_LARGE),
new Long(pos));
}
I also think this is the symmetry one would want for programming
convenience, like you have mentioned.
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12425588 ]
Craig Russell commented on DERBY-1516:
--
Hi Dag,
You know, I read this a hundred times and did not read it as allowing
t2.substring(1,1), since clearly 1 is beyond the length of the String.
substring(int beginIndex, int endIndex)
Throws:
IndexOutOfBoundsException - if the beginIndex is negative, or endIndex is
larger than the length of this String object, or beginIndex is larger than
endIndex.
But you are right and I'll change the implementation to support this. Much
cleaner indeed.
I will reimplement the test for the case of pos one beyond the length of the
Lob, which would now be legal. It would always return a zero-length result.
Thanks,
Craig
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,
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12425340 ]
Craig Russell commented on DERBY-1516:
--
There is different behavior between embedded and network in other areas as well
as the one I'm looking at here. I'd like to see what people think about this as
well. It's hard to add test cases for zero-length requests without
rationalizing the current behavior.
1. Both embedded and network do not return an error but truncate the result
when going past the end of the Clob. That is, ask a Clob with length 25 for 50
characters starting at position 1 and get 26 characters and no exception.
Proposal: Leave this behavior; we would need to add a new message, since the
current message SQLSTATE(XJ076): The position argument '5,910' exceeds the
size of the BLOB/CLOB cannot be used to describe running off the end of the
Clob. I'd like to see this changed in future, to match the java.lang.String
behavior, but this is a compatibility issue (existing applications might depend
on this behavior).
2. Different behavior for zero-length Clobs:
Embedded Clob with zero length: throws an exception trying to get any non-zero
length substring
Network Clob with zero length throws an exception only if the position is not
== 1.
Proposal: Change Network to throw an exception on any request to get a non-zero
length substring.
Craig
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424850 ]
Kathey Marsden commented on DERBY-1516:
---
The new positive cases sound fine to me.
If I understand all you wrote, you are saying that getSubstring(pos,0) where
pos the length of the clob should throw an exception for now while spec
clarification is underway. Is that correct? If so, that sounds good to me as
it is always *much* easier to change an exception case to work in the future if
need be. What we want to avoid is a situation where something works and then
we have to throw an exception later to be compliant. Can you add negative
cases for this to make sure we are throwing an appropriate exception? Then I
think all the needed zero length cases will be covered.
Thanks
Kathey
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.
--
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
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424887 ]
Craig Russell commented on DERBY-1516:
--
Thanks for the feedback. I'll make some positive and negative test cases and
update the patch.
Yes, I'm suggesting that we follow the java.lang.String specification and allow
for zero-length getSubString only if the position is legal. This is so there's
no special if (length == 0) { // ignore position for 0-length ...}. It actually
simplifies development.
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.
--
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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
Kathey Marsden [EMAIL PROTECTED] writes: 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?
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424636 ]
Kathey Marsden commented on DERBY-1516:
---
Thanks Craig for updating the masters.
I thiink it is really neat how specifying the patch of the same name grays out
the old patches but they are still available, seems like a great way to keep
our reworked patches organized.
- I still think it would be good to add some 0 length test cases before we
enable it to make sure behaviour is consistent between the two drivers.
Linking to derby-dev discussion
http://www.nabble.com/Re%3A--jira--Commented%3A-%28DERBY-1516%29-Inconsistent-behavior-for-getBytes-and-getSubString-for-embedded-versus-network-p5577797.html
I am not sure if the two drivers are consistent in this regard or what the
behavior is.
Kathey
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.
--
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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
Hi Dag,
I'd appreciate discussion on specific JIRA issues to be done in JIRA
instead on on the mailing list. I have a hard time tracking
discussions that are forked.
I'll comment on your comment in the JIRA.
Thanks,
Craig
On Jul 31, 2006, at 1:16 PM, Kathey Marsden (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1516?
page=comments#action_12424636 ]
Kathey Marsden commented on DERBY-1516:
---
Thanks Craig for updating the masters.
I thiink it is really neat how specifying the patch of the same
name grays out the old patches but they are still available, seems
like a great way to keep our reworked patches organized.
- I still think it would be good to add some 0 length test cases
before we enable it to make sure behaviour is consistent between
the two drivers. Linking to derby-dev discussion
http://www.nabble.com/Re%3A--jira--Commented%3A-%28DERBY-1516%29-
Inconsistent-behavior-for-getBytes-and-getSubString-for-embedded-
versus-network-p5577797.html
I am not sure if the two drivers are consistent in this regard or
what the behavior is.
Kathey
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.
--
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
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!
smime.p7s
Description: S/MIME cryptographic signature
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
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.
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.
--
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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
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.
[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424448 ]
Craig Russell commented on DERBY-1516:
--
Hi Kathey,
Thanks for the feedback on the patch. A few notes:
1. I've added myself to the derby-developers list so I can assign the issue to
myself.
2. The differences in the master blobclob4BLOB.out files shows the
inconsistency of the behaviors quite nicely.
3. I can update the master blobclob4BLOB.out files once we agree what we should
test. What I understand from you is that you would like to see lengths of 0,
-1, and -76 tested, and the master files updated. But the tests in question
clobTest6 and blobTest6 are negative tests that look for exceptions. It's not
clear to me that the test for 0 (which works for the network case) should be
tested here.
4. I noticed an unusual comment in clobTest6:
// 0 or negative position value
if (isDerbyNet)
System.out.println( negative tests for
clob.getSubstring won't run for network server until 5243 is fixed);
Can you translate this? What's a 5243?
Thanks,
Craig
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
Priority: Minor
Attachments: 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.
--
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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
Craig Russell (JIRA) wrote: 2. The differences in the master blobclob4BLOB.out files shows the inconsistency of the behaviors quite nicely. Yes I think analyzing (and eliminating) the master differences for client and embedded would be a great task associated with DERBY-310. 3. It's not clear to me that the test for 0 (which works for the network case) should be tested here. Yes I agree. Now that it is a positive case for both drivers it probably should be tested somewhere else. 4. I noticed an unusual comment in clobTest6: // 0 or negative position value if (isDerbyNet) System.out.println( negative tests for clob.getSubstring won't run for network server until 5243 is fixed); Can you translate this? What's a 5243? 5243 was a JCC bug with this description. JCC clob.getSubString() with a zero negative position or length argument gives a string index out of range exception It was marked fixed 3/23/2004 but unfortunately doesn't say exactly what version that was. I don't have access to the JCC bug database anymore, we'd just have to try and see if it is fixed for JCC 2.4 which is what the master is based on. Kathey
Re: [jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
Craig Russell (JIRA) wrote: what we should test. 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? Kathey
