[
https://issues.apache.org/jira/browse/DERBY-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886709#action_12886709
]
Yun Lee commented on DERBY-3898:
--------------------------------
When run org.apache.derbyTesting.functionTests.tests.jdbc4.BlobTest against
Revision 962387, I have 7 errors on testFreeandMethodsAfterCallingFree(),
testGetBinaryStreamLongLastByte(), testGetBinaryStreamLongDrain(),
testSetBytesReturnValueLargeStateChange(), testLockingAfterFree(),
testLockingAfterFreeWithRR() and testLockingAfterFreeWithDirtyReads(). They all
are in NetworkServer mode, and throw the identifical
java.lang.NoSuchMethodError: org.apache.derby.client.net.NetStatem
entRequest.writeScalarStream(ZZIILjava/io/InputStream;ZI)V.
exception snippet is below:
4) testGetBinaryStreamLongLastByte(org.apache.derbyTesting.functionTests.tests.j
dbc4.BlobTest)java.lang.NoSuchMethodError: org.apache.derby.client.net.NetStatem
entRequest.writeScalarStream(ZZIILjava/io/InputStream;ZI)V
at org.apache.derby.client.net.NetStatementRequest.buildEXTDTA(NetStatem
entRequest.java:983)
at org.apache.derby.client.net.NetStatementRequest.writeExecute(NetState
mentRequest.java:152)
at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPre
paredStatement.java:178)
at org.apache.derby.client.am.PreparedStatement.writeExecute(PreparedSta
tement.java:1787)
at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStat
ement.java:2017)
at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStateme
nt.java:1580)
at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatemen
t.java:1565)
at org.apache.derbyTesting.functionTests.tests.jdbc4.BlobTest.testGetBin
aryStreamLongLastByte(BlobTest.java:451)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
)
But I have found writeScalarStream() method in NetStatementRequest actually. Is
it OK on your computor, please?
> 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: 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.