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

stack commented on HBASE-1744:
------------------------------

What if you just did one or two of the filters for now?  If someone wants other 
filters on thrift-side bad enough, they can add them?

IMO, leave the admin functions out of your thrift machinations; e.g. 
closeRegion, getServerInfo, getStartKeys, etc.  Most of this utility can be 
done via shell.  If really wanted, could do in another issue?

The one exception to above rule would be revealing methods that might be used 
monitoring an hbase cluster; e.g. perhaps someone wants to write a perl script 
that checks cluster status and run it from cron.

Do you not have a close on the scanner?

OK on empty flag.

On 'T', yeah, should be consistent I'd say.

deleteSingle is fine by me.

Looking at hbase.thrift....

Stating the obvious, the package documentation is where you make your thrift 
explaination.

Purge 'Text'.  It doesn't seem to be used anyways and we went out of our way 
before you were born -- way back in 0.18/0.19 purging hadoop Text from hbase.

So, TResult is a map of the tuple family/qualifier/ts to value?  That should 
work.

Excellent Lars.


> 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: Hbase.thrift, 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