[
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 array:{quote}
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
{code}
ByteBuffer bb = <...>
byte[] arr = new byte[bb.remaining()];
bb.get(arr);
{code}
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.
