hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1744) Thrift server to match the new java api.
Date Sat, 05 Dec 2009 00:52:20 GMT

    [ 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.

View raw message