[
https://issues.apache.org/jira/browse/HBASE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878285#comment-13878285
]
Lars Hofhansl commented on HBASE-7320:
--------------------------------------
[~stack], sorry I am having a hard time phrasing this concisely.
The problem is that we currently assume two things:
# the entire KV is stored in one contiguous area in ram
# the key portion (row/family/qual/ts) is stored contiguously in ram
It is OK that the row key is stored contiguously in ram, same for the family,
qualifier, and value. I.e. we do not break up row-key, family, qualifier, or
value, but we do no longer assume the entire KV or the key-portion are in one
piece.
With that in mind things like getFamily, getFamilyArray, getFamilyOffset,
getFamilyLength (and same for row, qualifier, and value) are OK. But
getKeyLength, getLength, getBuffer, etc, are not OK.
Or in other words: To a caller it should not mater the the KV is stored in one
byte[] or whether there are separate byte[] for some or all of rowkey, family,
qualified, and value.
[~mcorgan], cool, so this *would* help with prefix trees. If families,
row-keys, qualifier are not broken down into fragments. How about the values,
can we assume them in one piece, still?
I also have to go back and think about timestamp.
> 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.98.0
>
>
> 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)
