[
http://issues.apache.org/jira/browse/DERBY-1341?page=comments#action_12414473 ]
Daniel John Debrunner commented on DERBY-1341:
----------------------------------------------
So I assume you are implementing the model where
DatabaseMetaData.locatorsUpdateCopy() method returns true, see section 16.3.3
of JDBC 3.0. Good to state this up front.
I aslo assume you have been following the discussion on the dev list (and in
another jira entry ?) about the defined semantics for the set methods
(overwrite or not etc.)
"Side effect of this impelementation is that the life time of lob is restrcited
till the transaction in which the objects are fetched. "
I thought that was the defined behaviour for Blob and Clob objects,
not just an implementation artifact?
"setBytes/String methods can use array/string field initially once the size
crosses initial threshold the data will be written into the file"
Why switch to a file if the object is already in-memory? Doesn't that
indicate there is enough memory to store it?
The StoreFactory was never intended to be used on the client, maybe it's
suitable, maybe it's not.
> 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
>
> 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
