hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7320) Remove KeyValue.getBuffer()
Date Fri, 14 Feb 2014 05:13:21 GMT

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

stack commented on HBASE-7320:

bq. Also I am still not getting the notion of using the same KeyValue.java class but use a
different codec? 

What are you referring to here [~ram_krish]?

bq. I think somewhere the codec type and the cell type used should be matched up? 

At the moment we have KeyValueCodec or CellCodec where the Codec is type particular in the
first case but not so in the second.  For first case, the decoder would return KeyValues.
 KeyValue implements Cell so it should pass through a Cell-based server fine.

We'd more want codecs like the second above where the type of Cell is not dictated by the
Codec.  The server just iterates the Codec and reconstitutes Cells as it thinks best.

But you know, I don't have this worked out end to end.  The Codecs and their API made sense
doing the RPC. Might not be best fit for in and out of hfiles (though I like the idea of the
hfile block being able to come up into block cache and our being able to keep blocks around
and have Cell iterators over them that rehydrate Cells only when necessary (and not if it
can be avoided).

bq. Some where in the code we are using KeyValue.getRow(), which currently returns the entire
byte[]. But that should be ideally keyvalue.getRowArray().

Yeah, that seems wrong.

> 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