[ 
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921924#action_12921924
 ] 

Lars Francke commented on HBASE-1744:
-------------------------------------

Services can extend each other so I can - in theory - extend the old API so 
both would be available in one server but I don't know if that is really a good 
option. I don't think it would be a technical problem though. The APIs are so 
different - I think they share some exceptions but that's it (and those are 
fine). Come to think of it: Both have a get(...) method if I remember correctly 
(Thrift does not know overloaded methods) so we'd have to rename one of the two.

Yeah unfortunately Thrift does not have any options for deprecating stuff so 
we'll just have to communicate it prominently.

The timeline I posted up there was purely fictional. Nothing stops us from 
keeping both APIs around. The maintenance overhead so far isn't that bad as far 
as I can tell. But we should make it very clear that one of the two is probably 
going away at some point to avoid confusion.

> 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.
-
You can reply to this email to add a comment to the issue online.

Reply via email to