[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_12424910 ] Anurag Shekhar commented on DERBY-1341: --- Thanks Fernanda for the test. I will prefer to keep LOBStreamControl's scope at the package. Let me try to modify the test so that it can still test the Streams. I am thinking of creating new blob using connection.createBlob and getting the stream from this blob to use in the test class you have written. 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 Issue Type: Improvement Components: JDBC Affects 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 Assigned To: Anurag Shekhar Fix For: 10.2.0.0 Attachments: derby-1341-blob-forreview.diff, derby-1341.diff, LobStreamTest.java 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
[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_12414473 ] Daniel John Debrunner commented on DERBY-1341: -- So I assume you are implementing the model where DatabaseMetaData.locatorsUpdateCopy() method returns true, see section 16.3.3 of JDBC 3.0. Good to state this up front. I aslo assume you have been following the discussion on the dev list (and in another jira entry ?) about the defined semantics for the set methods (overwrite or not etc.) Side effect of this impelementation is that the life time of lob is restrcited till the transaction in which the objects are fetched. I thought that was the defined behaviour for Blob and Clob objects, not just an implementation artifact? setBytes/String methods can use array/string field initially once the size crosses initial threshold the data will be written into the file Why switch to a file if the object is already in-memory? Doesn't that indicate there is enough memory to store it? The StoreFactory was never intended to be used on the client, maybe it's suitable, maybe it's not. 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
[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_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) Yes its the model where DatabaseMetaData.locatorsUpdateCopy() will return true (updates made on a copy) I am following the thread and plan to be consistant with client driver's behaviour unless its concluded other wise in that thread. Initially memory may be sufficient to hold the array user sets in. But user may call setBytes multiple times resulting in a huge array which may be stored in memory. Same is true when user is writing in the output stream. 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
[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_12414484 ] Anurag Shekhar commented on DERBY-1341: --- Initially memory may be sufficient to hold the array user sets in. But user may call setBytes multiple times resulting in a huge array which may be stored in memory. I mean may not be sotred in memory sorry about the typo 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
Re: [jira] Commented: (DERBY-1341) LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface
Anurag Shekhar (JIRA) wrote: [ 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 Yes its the model where DatabaseMetaData.locatorsUpdateCopy() will return true (updates made on a copy) I am following the thread and plan to be consistant with client driver's behaviour unless its concluded other wise in that thread. Initially memory may be sufficient to hold the array user sets in. But user may call setBytes multiple times resulting in a huge array which may be stored in memory. Same is true when user is writing in the output stream. 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.
[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_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
Re: [jira] Commented: (DERBY-1341) LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface
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=1553591tview=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.
RE: [jira] Commented: (DERBY-1341) LOB setBytes method(s) are currently no supported, but part of the Java 1.4 JDBC interface
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? 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. -- 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
[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. -- 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
