Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 13 Feb 2014 18:55:24 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12623342.1355211626765.38173.1392317724381@arcas>
In-Reply-To: <JIRA.12623342.1355211626765@arcas>
References: <JIRA.12623342.1355211626765@arcas>
Subject: [jira] [Commented] (HBASE-7320) Remove KeyValue.getBuffer()
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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 that.
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 together.

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
(v6.1.5#6160)