hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: Cleanup HTable public interface
Date Mon, 24 Feb 2014 23:42:25 GMT
If anything we'd move methods in. So far we've been strict and not leak implementation details
into the interface.
It might be prudent in the end to remove some methods from the HTable implementation and make
the functionality available through the HConnection only.

File a jira, Nick? We can discuss there.


-- Lars



________________________________
 From: Ted Yu <yuzhihong@gmail.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl <larsh@apache.org>

Sent: Monday, February 24, 2014 3:37 PM
Subject: Re: Cleanup HTable public interface
 

HTableInterface is marked with:

@InterfaceAudience.Public

@InterfaceStability.Stable

It would be tricky if we move some methods out.


Cheers





On Mon, Feb 24, 2014 at 3:32 PM, lars hofhansl <larsh@apache.org> wrote:

> +1. Let's clean it up before 1.0. Including a clean HTableInterface.
> The tricky part of HTableInterface was what to include in it. Up to this
> point the guiding principle was to expose nothing of the internal
> implementation (i.e. nothing about regions or start/end keys, etc).
>
>
> Thanks for stepping in and finish the job that I should have finished,
> Nick!
>
>
> -- Lars
>
>
>
> ________________________________
>  From: Nick Dimiduk <ndimiduk@gmail.com>
> To: hbase-dev <dev@hbase.apache.org>
> Sent: Monday, February 24, 2014 3:03 PM
> Subject: Cleanup HTable public interface
>
>
> 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. Can that be done for 1.0 as well?
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message