[
https://issues.apache.org/jira/browse/HBASE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14951509#comment-14951509
]
stack commented on HBASE-14398:
-------------------------------
Thank you for entertaining my commentary.
bq. IMO also getRowByteBuffer is better than getRow.
You have a point. It would match getRowArray up in Cell.
bq. So Stack, you agree to the idea of not throwing Exception when we call
getXXXArray() on a DBB backed cell. So here we will copy and return the byte[].
bq. Regarding getXXXOffset comment, u mean when the Cell is DBB backed, the
user has to assume the offset to be 0 always? That means again every where we
have to have instance of BBCell check.
I was thinking they would do getXXXOffset and if they'd used getXXXArray and a
copy had been made, then it would break horribly. I suppose your point is that
we need to smooth the transition so filters and CPs just keep working over
offheap (or Cells that are split over more than one BB) if they use the old
APIs even if it costs loads. Ok.
You two have made this argument with me a few times. We should integrate the
why into the Interface doc? I can write it up if that'd help.
Ok on the getXXXPosition.
> Create the fake keys required in the scan path to avoid copy to byte[]
> ----------------------------------------------------------------------
>
> Key: HBASE-14398
> URL: https://issues.apache.org/jira/browse/HBASE-14398
> Project: HBase
> Issue Type: Sub-task
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14398.patch, HBASE-14398_1.patch
>
>
> Already we have created some fake keys for the ByteBufferedCells so that we
> can avoid the copy requried to create fake keys. This JIRA aims to fill up
> all such places so that the Offheap BBs are not copied to onheap byte[].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
