[ http://issues.apache.org/jira/browse/DERBY-1341?page=all ]
Anurag Shekhar updated DERBY-1341:
----------------------------------
Attachment: derby-1341.diff
This diff is only for review of aprocah I am taking to resolve this issue.
I have introduced 3 new class in this patch. LOBStreamControl, LOBOutputStream
and LOBInputStream.
LOBStreamControl acts as wrpper on top of bytes stored in memory and the
temporary file on the file system. The read and write methods exposed by
LOBStreamControl are used by EmbeddedBlob and LOBXXXXStream.
when the total data size is less than 4k its stored in array once either the
setBytes on blob or write on Stream incheses the size more than 4k the data is
written into a temporrary file and subsequent operations are performed on the
file.
If call to truncate reduces the size of the file below 4k the data is again
moved back to memory.
Chanes made in EmbeddedBlob
Changed EmbeddedBlob to pass all the calls which were priviously acessing the
bytes array to LOBStreamControl.
> 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
> Type: Bug
> Components: JDBC
> 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
> Assignee: Anurag Shekhar
> Attachments: 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
