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
http://www.nabble.com/forum/ViewTopic.jtp?topic=1553591&tview=threaded#a4220683
regards,
--
Kristian
Best,
Keith
-----Original Message-----
From: Kristian Waagan (JIRA) [mailto:[EMAIL PROTECTED]
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 driver.
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 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
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.
