hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Francke (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1744) Thrift server to match the new java api.
Date Sun, 17 Oct 2010 13:39:22 GMT

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

Lars Francke commented on HBASE-1744:

{quote}So, you are going to have a thrift2 package for the new stuff. I don't know of any
other way of deprecating the old thrift api while introducing the new. Any ideas on how once
we remove the original thrift, of how we'd move thrift2 to thrift package?{quote}

That was the easiest option for now but if you have any other ideas? I could throw all that
stuff in the old package as well - I don't think there are any name-clashes. The only idea
I have for moving the stuff afterwards:

0.92: Deprecate thrift, introduce thrift2
0.94: Remove old thrift, deprecate thrift2, copy thrift2 to thrift
0.96: Remove thrift2

As I said: I can easily throw it all in the current thrift package I guess.

{quote}Why would I need an HBaseAdminPool? Why not just create one each time? Why have one
at all? Just let thriftians use shell if they want admin functionality?{quote}

That class is a remnant from an earlier patch I never finished. Not used at the moment. I
think an optional Thrift-Admin interface would be nice but I'll concentrate on the regular
client stuff for now.

{quote}IRC, this does not make a new array each time - it just returns the ByteBuffer backing

Yes that's the intention. I know it ain't the most proper way but it should work. Otherwise
I'd need to do something like
ByteBuffer bb = <...>
byte[] arr = new byte[bb.remaining()];
or use a CharsetDecoder or CharBuffer or something like that. I'm really not sure how to best
handle ByteBuffers. So any hint would be great.

{quote}There are missing licenses on new files and missing copyright header.{quote}

Thanks will fix that!

{quote}I'd imagine this has to be public for some reason else you'd make it private?{quote}

No that was just an oversight as far as I can see. Thanks, will look at it.

The rest you mentioned is not finished yet - it's just a literal copy & paste from the
old code (that's why the tests are commented out). I didn't change a thing yet. But it's on
my list.

I just thought it was about time I finally showed some results :)

And sure this can go into 0.92 - it has very little dependencies on the rest of the code
so I'll keep the patch updated if needed.

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

View raw message