db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [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 18:08:18 GMT


Anurag Shekhar (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1341?page=comments#action_12414483 ]

>
> Anurag Shekhar commented on DERBY-1341:
> ---------------------------------------
>
> I was wrong about life time of lob. It is supposed to restricted only for the transaction
(jdbc 3.0 section 16.3.1)
>   
For locator based that would be true.  However if it is  a copy , it 
could well live past the transaction.  This has been clarified in the 
jdbc 4 spec
> Yes its the model where DatabaseMetaData.locatorsUpdateCopy()  will return true (updates
made on a copy)
>
> I am following the thread and plan to be consistant with client driver's behaviour unless
its concluded other wise in that thread.
>
> Initially memory may be sufficient to hold the array user sets in. But user may call
setBytes multiple times resulting in a huge array which may be stored in memory. Same is true
when user is writing in the output stream.
>
>   
>> 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. 
>>  
>>     
>
>   

Mime
View raw message