hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7320) Remove KeyValue.getBuffer()
Date Thu, 13 Feb 2014 18:55:24 GMT

    [ https://issues.apache.org/jira/browse/HBASE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900599#comment-13900599

Lars Hofhansl commented on HBASE-7320:

bq. Currently everywhere in the code we are passing KeyValue in the args and also returning
keyvalue everywhere.
I think that not a problem per se, as long as nobody calls getBuffer, getKey, etc.
I have not quite wrapped my head around Cell vs. KeyValue. 

bq. KVComparator some of the apis still take KeyValue as the argument. I think we could change
We could and probably should. But we do not need to as long the comparator does not assume
anything beyond a continuous layout of row-key, family, column.

bq. In StoreFileScanner we do reseekTo and seekTo that seeks to a key ( this is not the rowkey).
So can we change this to the rowkey?
We're seeking to something identified by its coordinates, which in our case are row-key, family,
column identifier, and timestamp. Passing the "key" was just a convenient way to pass of these

Another tricky part is serialization and deserialization. We do not want to change the HFile
storage format (I think). It is not incorrect to deserialize a KeyValue into a single byte[]
(as long as nobody relies on it). So we could keep the current storage format and have serialization
code that generates it from the individual byte[]'s (i.e. we calculate the length and keylength
from the individual parts and then write them to the HFile just like it would have been written
now). Upon read we always deserilize into the current format.

> Remove KeyValue.getBuffer()
> ---------------------------
>                 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

View raw message