[
https://issues.apache.org/jira/browse/HBASE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882066#comment-13882066
]
stack commented on HBASE-7320:
------------------------------
bq. All calls to getBuffer() left are of two categories: access a KVs complete
key, access the KV as a whole, Now we need to fix those.
How you think we fix these Lars? Would the best approach now be to try and
implement a new Cell type altogether? That would shake out any reliance on KV?
bq. The next part is to get rid of the timestamp array API completely.
Can we change the Cell Interface ex post facto? Cell was published in 0.96.0?
Or could we deprecate the array accesses on timestamp and behind the scenes
return an array if asked but not use it in core codebase?
bq. After that, I think, is to writeTo/readFrom files. The writing side might
be simple as long we keep the format, in that case the reading side might not
have to change at all (it is still OK to back a Cell by a single byte[])
What is to be done here? Adding Cell Interfaces and moving over to use those?
Encoders?
bq, Big parts are: ScanQueryMatcher, which dissects the KV itself, and all the
comparators in KeyValue itself.
We would move to use Cell-base comparators rather than KV#comparators?
> Replace calls to KeyValue.getBuffer with appropropriate calls to getRowArray,
> getFamilyArray(), getQualifierArray, and getValueArray
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-7320
> URL: https://issues.apache.org/jira/browse/HBASE-7320
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: stack
> Fix For: 0.99.0
>
> Attachments: 7320-simple.txt
>
>
> In many places this is simple task of just replacing the method name.
> There, however, quite a few places where we assume that:
> # the entire KV is backed by a single byte array
> # the KVs key portion is backed by a single byte array
> Some of those can easily be fixed, others will need their own jiras.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
