db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5489) getBinary() returns incorrect data after getObject() call on BLOB column
Date Mon, 12 Mar 2012 08:27:40 GMT

    [ 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

        

Mime
View raw message