[
https://issues.apache.org/jira/browse/THRIFT-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908226#action_12908226
]
Bryan Duxbury commented on THRIFT-894:
--------------------------------------
bq. in TBaseHelper.byteBufferToByteArray we should check the target array's
size and either only copy as much data as will fit in it or not copy anything
if there is not enough room.
If there's not enough room, the way it works today is that they'll get an
ArrayIndexOutOfBoundsException. I can't think of any clearer way to indicate
that they've messed up than that. We certainly don't want to copy just a subset
of the data, as that would give very misleading results.
bq. Maybe bufferForXXX should be generated only if a special flag is set, or
maybe not at all. Does anyone have a use case for it?
I have a use case - say you're writing a datastore like Cassandra. You don't
want to have to copy binary fields ever if you can peer into the buffer to see
the bytes for keys and values. I don't see what benefit making bufferForXXX
optional would really give you. If you don't need it, you don't use it.
> Make default accessors for binary fields return byte[]; provide new accessors
> to get ByteBuffer version
> -------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-894
> URL: https://issues.apache.org/jira/browse/THRIFT-894
> Project: Thrift
> Issue Type: Improvement
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.5
>
> Attachments: thrift-894-v2.patch, thrift-894.patch
>
>
> Folks have pointed out that it's not always best for users to interact with
> the ByteBuffers that are now backing binary fields in our structs. In truth,
> it seems like ByteBuffers are probably an expert means of access, with
> associated benefits and complexities.
> I think we should generate two different sets of accessors for binary fields:
> a default set, named like usual, that return and take byte[], and a second
> set, named something like "get_buffer_for_<field>" that returns the
> underlying ByteBuffer. The byte[] accessors can wrap around the ByteBuffer
> ones as necessary.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
