db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@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 Tue, 30 May 2006 09:46:40 GMT
McFarlane, Keith GSNL-GSXE wrote:
>  Dear Kristian,
>  Good to have your support on this; and yes, I did mean setBytes throughout (getBytes
works fine). You spoke of support using the Derby Client. Is it a feasible solution to set
up a local (server-side) client as a "bridge"? What about security / encryption (hostile environment)
and performance?

Hello Keith,

Unless I have missed something, I guess "random access" to blobs cannot 
be done with the embedded driver yet (except from taking all out, 
editing and putting all back in).

You could try running a local network server and see how it works. This 
adds some complexity to your application when it comes to database 
administration (starting/stopping network server). The server can be 
configured to only accept connections from the localhost interface, and 
you can also enable authentication if you haven't already. Performance 
might be a bigger issue then security in this scenario...

*NB!* On the other hand, I suspect Derby's Blob.setBytes method does not 
behave as you expect. For simplicity, assume we have a Clob instead of a 
Blob; clob = "ABCDEFG". If you do a clob.setString(3, "XX"), what would 
you expect the result to be?
If the Blob behaves as the Clob in Derby, you will get "ABXX". I'm only 
guessing, but perhaps the JDBC team intended clob.truncate to be used 
for this, and that the setString method should have returned "ABXXEFG".

There is some discussion about this in 


>  Best,
>  Keith  
> -----Original Message-----
> From: Kristian Waagan (JIRA) [mailto:derby-dev@db.apache.org]
> Sent: 26 May 2006 08:50
> To: McFarlane, Keith GSNL-GSXE
> Subject: [jira] Commented: (DERBY-1341) LOB setBytes method(s) are
> currently no supported, but part of the Java 1.4 JDBC interface
>     [ http://issues.apache.org/jira/browse/DERBY-1341?page=comments#action_12413381 ]

> Kristian Waagan commented on DERBY-1341:
> ----------------------------------------
> (I assume the 'getBytes' in the description can be replaced with 'setBytes')
> Derby currently only supports the two setBytes methods for BLOB and CLOB in the client
> In the embedded driver, these methods are not yet implemented. I think this is an important
feature (for people using LOBs), and Derby should close this functionality gap.
> For a list of JDBC methods not supported by Derby, consult http://wiki.apache.org/db-derby/JDBCSupport
> The list is pretty new, so please correct errors if you spot any!
>> LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC
>> ------------------------------------------------------------------------------------------
>>          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
>>  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. 

View raw message