[
https://issues.apache.org/jira/browse/DERBY-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Øystein Grøvlen updated DERBY-2496:
-----------------------------------
Attachment: blobtestfix.diff
The patch, blobtestfix.diff, changes a few Junit tests to not expect Blob
objects to valid after transaction has committed. This is done in two ways:
1) Delay the closing of the result set until the Blob has been accessed.
2) Switch off autocommit.
The first change is used where possible, but where Blob objects obtained from
different statements are to be compared, autocommit can not be used. It is
safe to apply these test changes before the use of locators are enabled since
it a more restrictive lifespan for Blob objects are assumed.
The patch also contains two protocol fixes uncovered while running the tests
with locators enabled:
- The type of locator requested from the server depends on the nullability
of the column
- If the column value of zero is received, this is not a locator, but means
that length of LOB column is 0.
Also added bufferering to InputStreams in order to significantly reduce the run
time of some test cases.
derbyall has been run without errors. Junit All suite has been run with the
regular procedureInTrigger and encryption test errors.
File-by-file explanation of changes:
M
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/BlobTest.java
- Adjusted tests to not expect Blob objects to be valid after
transaction commit.
M
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/PreparedStatementTest.java
- Adjusted tests to not expect Blob objects to be valid after
transaction commit.
- Rewrote testSetBlobLengthless to take advantage of the existence of
Connection.createBlob
M
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/ResultSetTest.java
- Adjusted tests to not expect Blob objects to be valid after
transaction commit.
M java/client/org/apache/derby/client/net/NetCursor.java
- If the column value is zero, a locator was not sent. Instead, this
means that the length of the LOB is 0. Changed locator() to return
INVALID_LOCATOR when the column value is zero.
M java/client/org/apache/derby/client/net/NetStatementRequest.java
- If column is not nullable, a non-nullable locator must be requested.
Otherwise, the server will send an extra byte for nullability which
is not expected by the client.
M java/client/org/apache/derby/client/am/BlobLocatorOutputStream.java
- Added an assert that checks that the underlying Blob object is
locator based.
M java/client/org/apache/derby/client/am/Blob.java
- Add buffering for InputStreams by wrapping BlobLocatorInputStream in
a BufferedInputStream. (Doing the same for OutputStreams is not that
straight-forward since that requires that the stream is flushed
before the statement is executed.)
M java/client/org/apache/derby/client/am/BlobLocatorInputStream.java
- Removed a TAB. Client code is supposed to be a TAB-free zone!
> Implement Blob support for Locators
> -----------------------------------
>
> Key: DERBY-2496
> URL: https://issues.apache.org/jira/browse/DERBY-2496
> Project: Derby
> Issue Type: Sub-task
> Components: Network Server
> Reporter: Øystein Grøvlen
> Assigned To: Øystein Grøvlen
> Attachments: blob-followup.diff, blob-followup_v2.diff,
> blob-followup_v2.diff, blob.diff, blob_v2.diff, blobtestfix.diff
>
>
> DERBY-2347 adds the possibility to send locators between client and server
> instead of LOB values. This has not been activated yet, since the client
> implementation does not currently support locators. This report is for
> supporting the locators for Blob objects. Another JIRA issue will be made
> for Clob.
> This work will be made in several steps:
> 1. Blob methods and ResultSet.getXXX methods
> 2. PreparedStatement and CallableStatement methods
> 3. ResultSet.updateXXX methods
> 4. Connection.createBlob()
> There is dependencies between these steps and it might be that the Locator
> implementation cannot be exposed until everything has been done. At least,
> doing just step 1, gives testing errors because tests use Blobs fetched from
> DB as parameters to prepared statements. I would guess tests for updatable
> result sets, needs the combination of 1. and 3.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
