[ 
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)

Reply via email to