hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Cleanup HTable public interface
Date Mon, 24 Feb 2014 23:37:27 GMT
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