db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
Date Fri, 09 Mar 2012 12:24:58 GMT

    [ 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

        

Mime
View raw message