[
https://issues.apache.org/jira/browse/HBASE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901110#comment-13901110
]
ramkrishna.s.vasudevan commented on HBASE-7320:
-----------------------------------------------
bq.Could you implement a NoopDataBlockEncoder that writes the same format as
unencoded blocks?
This is the way that i started of when we wanted Tags in the hfiles.
bq.On HFile, it needs a redo especially when you come up through compressors
and codecs
Yes. I think we cannot have the stream as it is currently holding it. .May be
the serilization we could do, but the deserialization should not be so. It
should be based on the codec format.
I agree with Stack here.
Also I am still not getting the notion of using the same KeyValue.java class
but use a different codec? Should we have factory that reads the type of Cell
we would be using an then create those instances of Cell.
I think somewhere the codec type and the cell type used should be matched up?
Some where in the code we are using KeyValue.getRow(), which currently returns
the entire byte[]. But that should be ideally keyvalue.getRowArray().
> 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)
