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 <[email protected]> wrote:
> On Monday, February 24, 2014, Nick Dimiduk <[email protected]> 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.
>
