[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994573#comment-12994573
]
ryan rawson commented on HBASE-1744:
------------------------------------
talking about this recently with stack, I made the point that we should
probably put the new API in the same package/thrift file as the old. Use new
symbols, at the end of the .thrift file. That way people can use new and old
clients with the same server, making migration easier. It might make some names
a little ugly (we could go with the windowsy Ex suffix?) but making an easier
migration strategy is important I feel.
> Thrift server to match the new java api.
> ----------------------------------------
>
> Key: HBASE-1744
> URL: https://issues.apache.org/jira/browse/HBASE-1744
> Project: HBase
> Issue Type: Improvement
> Components: thrift
> Reporter: Tim Sell
> Assignee: Lars Francke
> Priority: Critical
> Fix For: 0.92.0
>
> Attachments: HBASE-1744.preview.1.patch, 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
