[
https://issues.apache.org/jira/browse/HBASE-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15347190#comment-15347190
]
Enis Soztutar commented on HBASE-15945:
---------------------------------------
bq. You can not plug in different versions of cpp libraries and expect them to
work.
Nobody expects binary compatibility. But it is still good to have source
compatibility for applications, so that they don't have to change code.
Our PB is fairly raw for a reason. Think about returning a row result (Result).
How would the API look like in pure PB? We expect the user to know about
associatedCellCount and know how to read from KeyValueCodec? What happens if we
change KVCodec? What happens if the results are PB Cell's. Applications will
deal with reading Cells two different way? We cannot have each and every
application deal with this complexity. Similar thing for MutationProto. How is
the user expected to send cells with the payload? Further, for batching /
MultiMutate / setting nonces, etc we have to construct additional PB's from the
client code. What about scanners? We directly expose ScanRequest and
ScanResponse and expect the user do scanner_id management, region boundaries,
etc? This does not make any sense.
Seems something to discuss in dev@
> Patch for Key Value, Bytes and Cell
> -----------------------------------
>
> Key: HBASE-15945
> URL: https://issues.apache.org/jira/browse/HBASE-15945
> Project: HBase
> Issue Type: Sub-task
> Reporter: Sudeep Sunthankar
> Assignee: Sudeep Sunthankar
> Attachments: HBASE-15945-HBASE-14850.v2.patch,
> HBASE-15945-HBASE-14850.v3.patch, HBASE-15945.HBASE-14850.v1.patch
>
>
> This patch contains an implementation of Key Value, Bytes and Cell modeled on
> the lines of Java implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
