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 <[email protected]> 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 <[email protected]> > To: "[email protected]" <[email protected]>; lars hofhansl < > [email protected]> > 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 <[email protected]> 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 <[email protected]> > > To: hbase-dev <[email protected]> > > 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? > > >
