[ 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
