hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HBASE-3250) Clean up HBaseAdmin APIs
Date Tue, 12 Aug 2014 19:11:17 GMT

     [ https://issues.apache.org/jira/browse/HBASE-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Andrew Purtell resolved HBASE-3250.

       Resolution: Duplicate
    Fix Version/s:     (was: 1.0.0)

This has been superseded by more recent issues.

> Clean up HBaseAdmin APIs
> ------------------------
>                 Key: HBASE-3250
>                 URL: https://issues.apache.org/jira/browse/HBASE-3250
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Todd Lipcon
> Some discussion on IRC about this - HBaseAdmin is a bit of a mess currently, it has a
lot of different calls. They tend to fall into these categories:
> - Things that actually affect the data from a user perspective (eg adding/dropping/enable/disable
tables, setting up CFs, etc)
> - Things that affect the underlying data storage (eg force split, flush, compact)
> - Cluster status (isMasterRunning, checkHBaseAvailable)
> I'd propose we separate these into different classes. HBaseAdmin would be reserved for
"DDL" operations (eg create/alter/drop table). A new class, eg HBaseRegionTools or HBaseStorageAdmin
or something, would handle the calls that affect "implementation details" like split/flush/compact.
The cluster status stuff should maybe just go in a new HBaseCluster class which would also
have getAdmin(), getTable(), etc?

This message was sent by Atlassian JIRA

View raw message