db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1341) LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface
Date Fri, 02 Jun 2006 16:38:31 GMT
    [ 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

> 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:,,,,,,,,,,,,,,
>  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:
For more information on JIRA, see:

View raw message