You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Nick Dimiduk <nd...@gmail.com> on 2014/02/25 00:03:36 UTC
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?
Re: Cleanup HTable public interface
Posted by Enis Söztutar <en...@apache.org>.
Great timing! I was also thinking of doing some work in this area. This
should be important for 1.0 API stability.
We already have HTableInterface which contains some of the methods, but the
name is too long. With HBASE-10479, the HConnection / HCM is cleaned a bit,
but we still have tens of deprecated methods.
I propose we do smt like this:
interface Table {
// get, put related stuff
}
@Deprecated
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
getAdmin()
// no deprecated methods (cache related etc)
}
@Deprecated
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
}
@Deprecated
class HCM extends ConnectionManager {
// users are encouraged to use ConnectionManager
}
interface Admin {
createTable()
deleteTable()
// 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. What do you guys think?
Enis
On Mon, Feb 24, 2014 at 3:14 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> On Monday, February 24, 2014, Nick Dimiduk <nd...@gmail.com> wrote:
> >
> > 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?
> >
>
> Related to this, I'm sure there are method overloads for accepting
> String/byte[]/TableName where just TableName is sufficient.
>
Re: Cleanup HTable public interface
Posted by Nick Dimiduk <nd...@gmail.com>.
On Monday, February 24, 2014, Nick Dimiduk <nd...@gmail.com> wrote:
>
> 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?
>
Related to this, I'm sure there are method overloads for accepting
String/byte[]/TableName where just TableName is sufficient.
Re: Cleanup HTable public interface
Posted by Stack <st...@duboce.net>.
On Mon, Feb 24, 2014 at 3:03 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> 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?
>
Music to my ears.
St.Ack
Re: Cleanup HTable public interface
Posted by Nick Dimiduk <nd...@gmail.com>.
I've opened HBASE-10602. Please apply appropriate opinions over there :)
I'm thinking it'll be an umbrella ticket with subtasks for each improvement.
On Mon, Feb 24, 2014 at 3:42 PM, lars hofhansl <la...@apache.org> wrote:
> 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 <yu...@gmail.com>
> To: "dev@hbase.apache.org" <de...@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 <la...@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 <nd...@gmail.com>
> > To: hbase-dev <de...@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?
> >
>
Re: Cleanup HTable public interface
Posted by lars hofhansl <la...@apache.org>.
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 <yu...@gmail.com>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>; lars hofhansl <la...@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 <la...@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 <nd...@gmail.com>
> To: hbase-dev <de...@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?
>
Re: Cleanup HTable public interface
Posted by Ted Yu <yu...@gmail.com>.
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 <la...@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 <nd...@gmail.com>
> To: hbase-dev <de...@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?
>
Re: Cleanup HTable public interface
Posted by lars hofhansl <la...@apache.org>.
+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 <nd...@gmail.com>
To: hbase-dev <de...@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?