[ http://issues.apache.org/jira/browse/DERBY-1341?page=comments#action_12414518 ]
Rick Hillegas commented on DERBY-1341: -------------------------------------- Lance Andersen adds: > > > [ > 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 > 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
