[jira] [Updated] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
[ 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] [Updated] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
[ 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] [Updated] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
[ 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
[ 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] [Updated] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
[ 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
[ 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
[ 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] [Updated] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
[ 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
[ 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] [Updated] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
[ 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] [Updated] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
[ 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
[ 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] [Updated] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
[
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
