[
https://issues.apache.org/jira/browse/HBASE-10531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923538#comment-13923538
]
ramkrishna.s.vasudevan commented on HBASE-10531:
------------------------------------------------
We had an internal discussion on this
As mentioned in my previous comments,
Making KVs to cells makes more sense in the Read path. And to do that we need
Cells in the readers and DBE seekers.
There are places where we do comparison with the index keys (doing a binary
search) and inside a block we compareflatkeys to see if we have gone past our
expected keys.
So when we are defining a cell which does not bother about how the key part
looks like and does not need an api like getKey(), getKeyOffset, getKeyLength()
then we are bound to depend on the cell structure. Hence we need to do our
comparisons with cells on both sides. Hence raised HBASE-10680.
Any more reviews on this? Thanks Lars for having a look at it.
> Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
> ------------------------------------------------------------------------
>
> Key: HBASE-10531
> URL: https://issues.apache.org/jira/browse/HBASE-10531
> Project: HBase
> Issue Type: Sub-task
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 0.99.0
>
> Attachments: HBASE-10531.patch, HBASE-10531_1.patch,
> HBASE-10531_2.patch
>
>
> Currently the byte[] key passed to HFileScanner.seekTo and
> HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts. And
> the caller forms this by using kv.getBuffer, which is actually deprecated.
> So see how this can be achieved considering kv.getBuffer is removed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
