db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anurag Shekhar (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 Wed, 31 May 2006 09:59:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1341?page=comments#action_12414019 ] 

Anurag Shekhar commented on DERBY-1341:
---------------------------------------

Currently the blob and clob can be constructed only by resultset. jdbc 4.0 connection object
does have methods to construct these methods but the absence of set methods in embedded driver
makes these objects (created by connection) useless. 

To implement these method I will be making some mdofication in the way behaviour of lob objects.


Currently the lob objects stores data either in an array (or string in case of clob)  or a
stream is constructed directly on top of linked field in store if the size of the lob stored
is found to be more than one page. Side effect of this impelementation  is that the life time
of lob is restrcited till the transaction in which the objects are fetched.


Client implementation assumes all of it can be kept in main memory but that doesn't looks
like a reasonable assumption. I can think of only one solution to handle this, by having a
temporary file. 

I am thinking of using the temp file from the StoreFactory. StoreFactory has methods to create
temporary file.


This is what I was thinking to implement (with assumption that I can use temp files) 

setBytes/String methods can use array/string field initially once the size crosses initial
threshold the data will be written into the file 
and further set methods will operate on file. In case the blob/clob size is smaller than 
threshold the data is copied in memory other wise a stream is attached with the object. I
haven't checked how this stream is created I am not sure if the stream is always operates
on store api as the blob and clob objects remain valid even after closing result set. 

setStream methods can return a custom stream which will initially store the data in memory
and once the threshold is reached it will use temp file. 

While setting the blob/clob into prepared statement internally it will call setString/setBytes
in case the data is in memory and setStream in case the temp file is in use. 



> 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


Mime
View raw message