[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921787#action_12921787
]
stack commented on HBASE-1744:
------------------------------
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?
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?
IIRC, this does not make a new array each time -- it just returns the
ByteBuffer backing array:
{code}
+ HTableInterface htable = getTable(table.array());
{code}
I like your getFromThrift and getFromHBase namings.
Oh, nice, you are doing multiget (and multiput)... and incrementColumnValues.
There are missing licenses on new files and missing copyright header.
I'd imagine this has to be public for some reason else you'd make it private?
{code}
+ public ThriftServer() {
{code}
This is cool:
{code}
+ options.addOption("f", "framed", false, "Use framed transport");
+ options.addOption("c", "compact", false, "Use the compact protocol");
{code}
Just remove this I'd say:
{code}
+ public void testAll() throws Exception {
..
{code}
Start cluster once rather than per test?
{code}
+ @Before
+ public void setUp() throws Exception {
{code}
Oh, all tests are commented out? Or some of them?
Hmmm... looks kinda great to me Lars.
On what I said on IRC, I'd say, we can let this be 0.92. 0.92 is soon after
0.90 so that should help. Meantime anyone who needs new thrift can apply this
patch?
> 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.
