[
https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988092#comment-13988092
]
Enis Soztutar commented on HBASE-10602:
---------------------------------------
I was thinking about how to do a good API for the admin operations like flush,
compact, createTable, etc. We already know that we should provide a default
async API (or half-async), but with the possibility of the client waiting for
the operation results, and query the status later. It has been a discussed (in
the master redesign issue, and by Stack in RB for this issue) that at the RPC
layer, we would want to fire up a request like createTable to master, and get a
token back so that we can query the results later with it. But the client level
API does not need to be exposed to tokens etc.
I am thinking of using Future's for this. What do you guys think?
{code}
public Future<CompactRegionResult> compactRegion();
{code}
For Table APIs like Put, and Get, we might want the same thing. For puts, we
won't have setAutoFlush(). We will have either putSync() or put()
{code}
public boolean putSync(Put);
public Future<PutResult> put(Put);
{code}
[~nkeywal] was talking about being able to inject a callback between retries so
that the user has greater control. For that though, a callback based API seems
more appropriate.
> Cleanup HTable public interface
> -------------------------------
>
> Key: HBASE-10602
> URL: https://issues.apache.org/jira/browse/HBASE-10602
> Project: HBase
> Issue Type: Improvement
> Components: Client, Usability
> Reporter: Nick Dimiduk
> Assignee: Enis Soztutar
> Priority: Blocker
> Fix For: 0.99.0
>
> Attachments: hbase-10602_v1.patch
>
>
> HBASE-6580 replaced the preferred means of HTableInterface acquisition to the
> HConnection#getTable factory methods. HBASE-9117 removes the HConnection
> cache, placing the burden of responsible connection cleanup on whomever
> acquires it.
> The remaining HTable constructors use a Connection instance and manage their
> own HConnection on the callers behalf. This is convenient but also a
> surprising source of poor performance for anyone accustomed to the previous
> connection caching behavior. I propose deprecating those remaining
> constructors for 0.98/0.96 and removing them for 1.0.
> While I'm at it, I suggest we pursue some API hygiene in general and convert
> HTable into an interface. I'm sure there are method overloads for accepting
> String/byte[]/TableName where just TableName is sufficient. Can that be done
> for 1.0 as well?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
