[
https://issues.apache.org/jira/browse/DERBY-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yun Lee updated DERBY-3898:
---------------------------
Attachment: derby-3898-testcase.stat
derby-3898-testcase.patch
In derby-3898-testcase.patch, I have added 7 test cases in BlobTest.java to
test the boundary of setBytes() method, each of them run in both Embed and
NetworkServer modes. For the current revision, I get 2 erors and 1 failure. It
suggests that there are 3 differences between embedded and client driver, 2 of
them are about length, and the third is about offset. In particular, it works
like below:
a.
public void testSetBytesWithTooLongLength() throws SQLException {
Blob blob = getConnection().createBlob();
try{
blob.setBytes(1, new byte[] {0x69}, 0, 2);
fail("IndexOutOfBoundsException should be thrown out for " +
"wrong argument for Blob.setBytes()!");
} catch (IndexOutOfBoundsException e) {
assertTrue(true);
}
}
This is what this issue is talking about. It has been agrred that "Embedded
is correct" as it throws a IndexOutOfBoundsException by System.arrayCopy().
However, should it be wrapped into a SQLException with
SQLState.BLOB_LENGTH_TOO_LONG to provide exact info.
b.
public void testSetBytesWithNonPositiveLength() throws SQLException {
Blob blob = getConnection().createBlob();
try{
blob.setBytes(1, new byte[] {0x69}, 0, -1);
} catch (SQLException sqle) {
assertSQLState("XJ071", sqle);
}
}
It passes in NetworkServer mode, but fails in Embed mode by throwing an
ArrayIndexOutOfBoundsException. Obviously, in both modes Blob.setByets() has
catch the nonpositive length, but it doesn't give a consistent exception. Maybe
it's best to also throw out a SQLException. in Embed mode.
c.
public void testSetBytesWithInvalidOffset() throws SQLException {
Blob blob = getConnection().createBlob();
try {
blob.setBytes(1, new byte[] {0xb}, -1, 1);
} catch (SQLException sqle) {
assertSQLState("XJ078", sqle);
}
try {
blob.setBytes(1, new byte[] {0xb}, 2, 1);
} catch (SQLException sqle) {
assertSQLState("XJ078", sqle);
}
try {
blob.setBytes(1, new byte[] {0xb, 0xe}, Integer.MAX_VALUE, 1);
} catch (SQLException sqle) {
assertSQLState("XJ078", sqle);
}
}
As b., c. passes in NetworkServer mode, but fails in Embed mode by throwing an
ArrayIndexOutOfBoundsException. Obviously, in both modes Blob.setByets() has
catch the nonpositive length, but it doesn't give a consistent exception. Maybe
it's best to also throw out a SQLException in Embed mode.
Should we create two new issues for b. and c. and provide the same patch for 3
of them? And welcome to enrich relative test cases before patch available!
> Blob.setBytes differs between embedded and client driver when the specified
> length is invalid
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-3898
> URL: https://issues.apache.org/jira/browse/DERBY-3898
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.1.0
> Reporter: Kristian Waagan
> Assignee: Yun Lee
> Priority: Minor
> Attachments: derby-3898-testcase.patch, derby-3898-testcase.stat,
> Derby3898.java
>
>
> Blob.setBytes behaves differently with the embedded driver and the client
> driver.
> Assume a 1 byte array and a specified length of 2: Blob.setBytes(1, new
> byte[] {0x69}, 0, 2)
> Embedded: IndexOutOfBoundsException (from java.io.RandomAccessFile.writeBytes
> or System.arraycopy)
> Client: succeeds, returns insertion count 1
> The behavior should be made consistent, but what is the correct behavior?
> From the Blob.setBytes JavaDoc:
> "Writes all or part of the given byte array to the BLOB value that this Blob
> object represents and returns the number of bytes written. Writing starts at
> position pos in the BLOB value; len bytes from the given byte array are
> written. The array of bytes will overwrite the existing bytes in the Blob
> object starting at the position pos. If the end of the Blob value is reached
> while writing the array of bytes, then the length of the Blob value will be
> increased to accomodate the extra bytes."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
