You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Pawel Fronczak (Created) (JIRA)" <ji...@apache.org> on 2011/10/31 23:53:32 UTC
[jira] [Created] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
getBinary() returns incorrect data after getObject() call on BLOB column
------------------------------------------------------------------------
Key: DERBY-5489
URL: https://issues.apache.org/jira/browse/DERBY-5489
Project: Derby
Issue Type: Bug
Affects Versions: 10.8.2.2, 10.7.1.1
Reporter: Pawel Fronczak
When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5489:
-----------------------------------
Attachment: derby-5489-2a-fixes.diff
Attaching patch 2a, which implements the checks to make getBytes, getString, and getObject throw an exception when invoked on a LOB column after another getter has already has been invoked, and harmoinzes the behavior for the embedded and the client driver.
As already noted, getBytes and getString currently behave differently than the rest. It is allowed to call those two getters repeatedly because they materialize the value.
Examples of behavior with the patch:
(I'm using getObject, but it could be any of the other valid getters for LOBs)
a) OK: getBytes - getBytes
b) FAILS: getObject - getBytes
c) OK: getBytes - getObject
d) FAILS: getBytes - getObject - getBytes
e) FAILS: getBlob - getBinaryStream
The changes to lang.UpdatableResultSetTest adjust the access pattern to be compatible with the new rules/restrictions.
Assuming everything else is ok, it must be decided if we want to keep the special behavior for getBytes and getString (i.e. either remove the TODOs, or modify the implementation).
I've successfully run suites.All with the patches:
15488 tests executed
0 errors
0 failures
Patch ready for review.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Mamta A. Satoor (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor updated DERBY-5489:
-----------------------------------
Issue & fix info: Repro attached
Urgency: Normal
Bug behavior facts: Embedded/Client difference,Wrong query result (was: Wrong query result)
Labels: derby_triage10_9 (was: )
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Dag H. Wanvik
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Dag H. Wanvik (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151748#comment-13151748 ]
Dag H. Wanvik commented on DERBY-5489:
--------------------------------------
I found I could reproduce the error in a simplified repro (without Spring dependencies) using the uploaded Repro.diff (diff against BLOBTest.java in the regressions suite).
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5489:
-----------------------------------
Attachment: derby-5489-2b-fixes.diff
Attaching patch 2b:
o ResultSet and EmbedResultSet:
Adds the required checks to behave as specified (see above). Factored out method checkLOBMultiCall(int). In the client driver I added a missing check for getObject.
o UpdatableResultSetTest:
Made access pattern compatible with the new behavior. The test worked because it always called a getter that materialized the value first, or the value was so small that it was kept in a materialized representation.
o jdbcapi/LobRsGetterTest:
Renamed some methods (only actual test methods now start with "test", the private ones I renamed to "_test").
Added some more comments, and two more tests. The tests verifies the content of LOB in various scenarios when multiple getters are invoked.
o jdbcapi/_Suite:
Enabled the test as part of the test suite.
Patch ready for final review.
Tests passed on Linux and Solaris with JDK 1.6.
I intend to commit this patch tomorrow at the latest.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, derby-5489-2b-fixes.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259535#comment-13259535 ]
Kristian Waagan commented on DERBY-5489:
----------------------------------------
I committed the test (patch 1b) to trunk with revision 1329186.
Thank you for your opinion, Knut Anders.
Based on your feedback and my own opinion, I will keep the special treatment of getBytes and getString.
Regarding the suggested refactoring, I will do so to more clearly document the special treatment. Note that the getters belong to two different result set implementations, so I still need two helper methods.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272769#comment-13272769 ]
Dag H. Wanvik commented on DERBY-5489:
--------------------------------------
I suggest you omit saying anything about that (for simplicity also).
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_triage10_9
> Fix For: 10.9.0.0
>
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, derby-5489-2b-fixes.diff, releaseNote.html, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Dag H. Wanvik (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-5489:
---------------------------------
Assignee: (was: Dag H. Wanvik)
Unassigning myself, not actively working on this.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224665#comment-13224665 ]
Kristian Waagan commented on DERBY-5489:
----------------------------------------
The Spring Framework issue has been logged as SPR-8810 [1].
[1] https://jira.springsource.org/browse/SPR-8810
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Dag H. Wanvik
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Dag H. Wanvik (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik reassigned DERBY-5489:
------------------------------------
Assignee: Dag H. Wanvik
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Dag H. Wanvik
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Pawel Fronczak (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141336#comment-13141336 ]
Pawel Fronczak commented on DERBY-5489:
---------------------------------------
The problem with changing the code responsible for the data retrieval is that it is part of the SpringFramework library. Since it seems that it is opposing the JDBC API, I shall file a bug report for that.
Fortunately, there is a simple workaround - instead of using the queryForList() method, one could use the query() method and supply custom RowMapper (or RowCallbackHandler) which will read the BLOB column only once.
Nevertheless, an exception from getBytes explaining what has happened would be very helpful. Right now it is not very easy to track down the cause of the problem.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Attachments: SelectBlobBug.java
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258175#comment-13258175 ]
Knut Anders Hatlen commented on DERBY-5489:
-------------------------------------------
The new checks that are added to the getters look almost identical. Would it be possible to factor them out in a shared helper method?
> Assuming everything else is ok, it must be decided if we want to keep the special behavior for getBytes and getString
I'm fine with it either way. The advantage of not having special treatment of getBytes and getString is that the behaviour is easier to explain: LOB columns can only be accessed once. But keeping the special treatment reduces the chances of breaking existing applications, and I don't see any significant downside, so I think I'm leaning towards the approach you chose in the 2a patch.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5489:
-----------------------------------
Attachment: derby-5489-1a-test.diff
Attaching a first version of a test as patch 1a.
A few comments:
o expects getBytes on BLOB and getString on CLOB to be supported
o additionally, we support getString, getAsciiStream, and getCharacterStream on BLOB (note differing behavior regarding how the raw bytes are interpreted, see JDBC implementation notes on the Derby web site)
o as an exception to the rule, multiple invocations of getString/getBytes is supported as long as no other getter has been invoked previously. This works because those getters always materialize. Do we want to keep this exception to the rule as a convenience, or should we go for consistency?
o the behavior between embedded and client differs on several accounts
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Pawel Fronczak (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pawel Fronczak updated DERBY-5489:
----------------------------------
Component/s: JDBC
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Attachments: SelectBlobBug.java
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227366#comment-13227366 ]
Knut Anders Hatlen commented on DERBY-5489:
-------------------------------------------
> The work mentioned above is probably not suitable for backporting,
> but as an an alternative we could use the mechanism that disallows
> multiple accesses of the same LOB/stream column on a single row to
> improve the situation on 10.8 and earlier.
If we take the trouble to implement this solution for 10.8 and
earlier, couldn't we do the same for trunk? It sounds like it fixes
the same problem, but with a much smaller compatibility impact.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5489:
-----------------------------------
Attachment: releaseNote.html
Attaching a first attempt at a release note.
It doesn't say anything about the fact that you can invoke getBytes/getString multiple times. Should it, given that one of the purposes of a release note is to determine if an upgrade will cause your application to break?
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_triage10_9
> Fix For: 10.9.0.0
>
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, derby-5489-2b-fixes.diff, releaseNote.html, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Dag H. Wanvik (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213660#comment-13213660 ]
Dag H. Wanvik commented on DERBY-5489:
--------------------------------------
Data point: I don't see this issue with the client driver.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Dag H. Wanvik
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226117#comment-13226117 ]
Kristian Waagan commented on DERBY-5489:
----------------------------------------
Thanks, Kim!
I'll keep that in mind, but will hold off until we're sure we want to forbid those methods on LOB columns.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Dag H. Wanvik (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-5489:
---------------------------------
Attachment: repro.diff
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5489:
-----------------------------------
Issue & fix info: Release Note Needed,Repro attached (was: Repro attached)
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_triage10_9
> Fix For: 10.9.0.0
>
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, derby-5489-2b-fixes.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-5489:
----------------------------------
Labels: derby_backport_reject_10_8 derby_triage10_9 (was: derby_triage10_9)
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_backport_reject_10_8, derby_triage10_9
> Fix For: 10.9.1.0
>
> Attachments: derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, derby-5489-2b-fixes.diff, releaseNote.html, repro.diff, SelectBlobBug.java
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13228447#comment-13228447 ]
Kristian Waagan commented on DERBY-5489:
----------------------------------------
I've been talking to Lance Anderson, the JDBC spec lead, and the intention is to specify that getBytes is supported on BLOB columns in a future release/update of the JDBC specification. The same goes for getString on CLOB columns. The recommended way to access a BLOB is still through getBlob.
This makes it clear that we must allow getBytes on BLOB columns, but the existing restriction we have on calling a getter only once on a LOB column will still be there.
Knut, the answer to your question is definitely yes :)
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226039#comment-13226039 ]
Kristian Waagan commented on DERBY-5489:
----------------------------------------
According to the JDBC specification, using getBytes on a BLOB column isn't allowed. This is stated in table B-6 and the following text:
"""
TABLE B-6 Type Conversions Supported by ResultSet getter Methods
This table shows which JDBC types may be returned by ResultSet getter methods. A
bold X indicates the method recommended for retrieving a JDBC type. A plain x
indicates for which JDBC types it is possible to use a getter method.
"""
There is no x/X in the cell where getBytes and BLOB intersects.
If this is correct, I will create a new JIRA to track the work on forbidding this in Derby since the title of this issue doesn't express what is changing very well. This change will most likely have consequences for some existing applications and will require a release note.
The work mentioned above is probably not suitable for backporting, but as an an alternative we could use the mechanism that disallows multiple accesses of the same LOB/stream column on a single row to improve the situation on 10.8 and earlier. That means applications using only ResultSet.getBytes() on a BLOB will continue to work, whereas applications using ResultSet.get[Blob|BinaryStream|Object] plus getBytes will fail. Failing with an exception is preferable to data corruption/wrong results. Some applications may not see the data corruption/wrong results - I believe this will be the case if the BLOBs are below a given threshold (represented in-memory vs store stream). Based on Dag's comment this may also be the case for applications using the client driver (independent of the BLOB size).
I haven't verified it, but I suspect there will be similar issues to fix for CLOB.
Any opinions on my interpretation of the JDBC specification, and on the suggested improvements?
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan resolved DERBY-5489.
------------------------------------
Resolution: Fixed
Fix Version/s: 10.9.0.0
Issue & fix info: Repro attached (was: Repro attached,Patch Available)
Committed patch 2b to trunk with revision 1330681.
Unless something new comes up, I don't plan more work on this issue.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_triage10_9
> Fix For: 10.9.0.0
>
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, derby-5489-2b-fixes.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5489:
-----------------------------------
Attachment: derby-5489-1b-test.diff
Attaching patch 1b, a slightly updated version of the test. Only naming, typos, and comments have been changed.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kim Haase (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226103#comment-13226103 ]
Kim Haase commented on DERBY-5489:
----------------------------------
You may also want to file a documentation issue, Kristian -- the following topic mentions using getBytes with a BLOB, and getString with a CLOB:
http://db.apache.org/derby/docs/dev/ref/rrefjdbc96386.html
Topics elsewhere in the docs mention only the use of getBlob and getClob, fortunately.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-5489:
-----------------------------------
Issue & fix info: Patch Available,Repro attached (was: Repro attached)
Assignee: Kristian Waagan
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Assignee: Kristian Waagan
> Labels: derby_triage10_9
> Attachments: SelectBlobBug.java, derby-5489-1a-test.diff, derby-5489-1b-test.diff, derby-5489-2a-fixes.diff, repro.diff
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Pawel Fronczak (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pawel Fronczak updated DERBY-5489:
----------------------------------
Attachment: SelectBlobBug.java
I have attached a code snippet reproducing this bug.
It requires the springframework-jdbc library to operate.
The mentioned sequence of getObject / getBytes methods is buried inside the JdbcTemplate.queryForList method:
Object obj = rs.getObject(index);
(...)
if (obj instanceof Blob) {
obj = rs.getBytes(index);
}
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Attachments: SelectBlobBug.java
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5489) getBinary() returns incorrect data
after getObject() call on BLOB column
Posted by "Kristian Waagan (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141065#comment-13141065 ]
Kristian Waagan commented on DERBY-5489:
----------------------------------------
I think we decided to forbid accessing the same column (on the same row) multiple times for streams and LOBs (I can't find the JIRA issue right now). It may be an oversight that getBytes doesn't throw an exception in this case. The decision was based partly on the following text for the Java API documentation for java.sql.ResultSet:
"For maximum portability, result set columns within each row should be read in left-to-right order, and each column should be read only once."
getString appears to have the same issue.
A possible change/fix for the code above would be to cast obj to Blob and use one of the java.sql.Blob methods to obtain the bytes. One could also rewrite the code to chose the correct action based on metadata instead of the type of the object returned by getObject, I suppose.
I have not looked at actually fixing the Derby positioning bug itself.
> getBinary() returns incorrect data after getObject() call on BLOB column
> ------------------------------------------------------------------------
>
> Key: DERBY-5489
> URL: https://issues.apache.org/jira/browse/DERBY-5489
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.7.1.1, 10.8.2.2
> Reporter: Pawel Fronczak
> Attachments: SelectBlobBug.java
>
>
> When ResultSet.getObject(int) is called on a BLOB column, the correct EmbedBlob object is returned. But if afterwards the ResultSet.getBytes(int) is called on the same row, the returned array contains invalid data - it is offset by 3 bytes and its size is incorrect.
> The problem only occurs when the stored BLOB is large enough to be internally represented by stream and not by array of bytes (at least ~32KiB).
> It seems that the getObject method shifts the stream position and therefore the getBytes method starts to read the data after the third byte, thus incorrectly calculating its length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira