[ http://issues.apache.org/jira/browse/DERBY-1341?page=all ]
Anurag Shekhar updated DERBY-1341:
----------------------------------
Attachment: derby-1341-blob-forreview.diff
This patch is only for review.
After the review I will be uploading the complete patch (blob and clob) and the
test case. I plan to use same approach for clob implementation too.
In this patch I have modified the LOBStreamContrl to use storage factory for
temporary file. Rest of the code is same as the privious patch.
My final patch will have following
1. Implementation for Blob and Clob.
2. Test cases.
3. I will be adding one more method in StorageFactory to generate unique
temporary file (similar to the method in java.io.File)
> LOB setBytes method(s) are currently no supported, but part of the Java 1.4
> JDBC interface
> ------------------------------------------------------------------------------------------
>
> Key: DERBY-1341
> URL: http://issues.apache.org/jira/browse/DERBY-1341
> Project: Derby
> Issue Type: Improvement
> Components: JDBC
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0,
> 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3,
> 10.3.0.0, 10.1.2.4, 10.1.2.5
> Environment: Windows 2000
> Reporter: Keith McFarlane
> Assigned To: Anurag Shekhar
> Fix For: 10.2.0.0
>
> Attachments: derby-1341-blob-forreview.diff, derby-1341.diff
>
>
> JDBC LOB . getBtypes methods are not implemented in any Derby version to
> date: there is a "place-holder" method that throws a SQLException reporting
> that the methods are not implemented.
> It would be excellent to have any efficient Derby implementation of the
> getBytes LOB methods that provide "random-access" to the binary // character
> content of database large objects. The specific context is implementing a
> Lucene Directory interface that stores indexing data (index files) and other
> binary data in a local encrypted Derby instance.
> A work around is to write an encrypted RandomAccessFile implementation as a
> file-sdystem buffer, perhaps writing to the database on closure. An efficient
> Derby implementation of LOB . getBytes would avoid this an make for a clean
> design. I can think of several reasons why random-access to LOBs would be
> valuable in a "hostile" client environment.
>
--
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
