hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10602) Cleanup HTable public interface
Date Tue, 25 Feb 2014 01:09:27 GMT

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

Enis Soztutar commented on HBASE-10602:

Let me repeat my comments from dev@ for further discussion here.I propose we do smt like this:

interface Table {
  // get, put related stuff

interface HTableInterface extends Table {
  // users are encouraged to use the new Table interface

class HTable extends Table {
  // all HTable constructors are deprecated
  // Users are not encouraged to see this class

interface Connection extends Closeable{
  getTable(), and rest of HConnection methods 
  // no deprecated methods (cache related etc)

interface HConnection extends Connection {
  // users are encouraged to use Connection

class ConnectionManager {
  createConnection(Configuration) // not sure whether we want a static factory method to create
connections or a ctor

class HCM extends ConnectionManager {
  // users are encouraged to use ConnectionManager

interface Admin {
  // only truly client-facing public methods here

class HBaseAdmin extends Admin {
  // all constructors are deprecated

We can introduce this as the default new API, and announce some stability support for these
in the 1.x line

> 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
>             Fix For: 0.99.0
> 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

View raw message