[ 
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

        

Reply via email to