[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783371#action_12783371
]
ryan rawson commented on HBASE-1744:
------------------------------------
It is a big deal for us to keep the current thrift API, we'd have to have a
flag day and change our clients and servers at the same time, not ideal.
It would be best if we could have both APIs available (that is how we did the
0.19 -> 0.20 (ish) migration).
> Thrift server to match the new java api.
> ----------------------------------------
>
> Key: HBASE-1744
> URL: https://issues.apache.org/jira/browse/HBASE-1744
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: thrift
> Reporter: Tim Sell
> Assignee: Tim Sell
> Fix For: 0.21.0
>
> Attachments: thriftexperiment.patch
>
>
> This mutateRows, etc.. is a little confusing compared to the new cleaner java
> client.
> Thinking of ways to make a thrift client that is just as elegant. something
> like:
> void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
> with:
> struct TColumn {
> 1:Bytes family,
> 2:Bytes qualifier,
> 3:i64 timestamp
> }
> struct TPut {
> 1:Bytes row,
> 2:map<TColumn, Bytes> values
> }
> This creates more verbose rpc than if the columns in TPut were just
> map<Bytes, map<Bytes, Bytes>>, but that is harder to fit timestamps into and
> still be intuitive from say python.
> Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
