[
https://issues.apache.org/jira/browse/HBASE-15893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15308973#comment-15308973
]
Enis Soztutar commented on HBASE-15893:
---------------------------------------
bq. There's no need to have a byte comparable when string already has all that.
Agreed, we can either use strings directly, or typedef BYTE_ARRAY as a string.
Our KV can be something like:
https://github.com/google/leveldb/blob/master/include/leveldb/slice.h.
bq. Don't need cell and key value. There's no off heap. We've made no promises
about kv's aways being in the same contiguous memory so there's no need to have
the distinction.
We still need a way to represent the "data model" of a cell (give me the row
keys from underlying row) etc. However, one direction that we can follow is
like the flatbuffers approach where every "cell" is a string, and we have KV as
an accessor-type object, not instantiated per instance. This will work with
KeyValueCodec, but not with any other codec that we can improve. The Cell
interface is not just for off-heap KV versus on-heap. The CellCodec can encode
and re-use the same underlying byte[]s for the rowKey, CF, etc across cells. I
think we do not want to limit ourselves to only be able to KV representation in
RPC. So I would opt for a Cell-like interface type where the scan's Result's
can be encoded more efficiently. For that, we still need a Cell interface, and
a concrete KV implementation. However, we can make KV a private class, not part
of the public API.
Let's create a separate jira for KV + Cell + Bytes as a foundational patch for
rest of Get / Put, etc.
> Get object
> ----------
>
> Key: HBASE-15893
> URL: https://issues.apache.org/jira/browse/HBASE-15893
> Project: HBase
> Issue Type: Sub-task
> Reporter: Sudeep Sunthankar
> Attachments: HBASE-15893.HBASE-14850.v1.patch
>
>
> Patch for creating Get objects. Get objects can be passed to the Table
> implementation to fetch results for a given row.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)