Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 18 Aug 2015 10:19:45 +0000 (UTC)
From: "Jingcheng Du (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12856376.1439659485000.93306.1439893185819@Atlassian.JIRA>
In-Reply-To: <JIRA.12856376.1439659485000@Atlassian.JIRA>
References: <JIRA.12856376.1439659485000@Atlassian.JIRA>
 <JIRA.12856376.1439659485250@arcas>
Subject: [jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into
 existing APIs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14701043#comment-14701043 ] 

Jingcheng Du commented on HBASE-14227:
--------------------------------------

bq. There is no need to do this. If CF is passed in, we can check schema option to decide whether the CF is MOB or not
Compacting the store files with ref cells and mob files are different. But they share the same CF. We want to separate the compactions, and we have to separate these operations in methods. If only with CF, we only know the cf is a mob-enable cf, but we don't know what kind of compaction is needed.

> Fold special cased MOB APIs into existing APIs
> ----------------------------------------------
>
>                 Key: HBASE-14227
>                 URL: https://issues.apache.org/jira/browse/HBASE-14227
>             Project: HBase
>          Issue Type: Task
>          Components: mob
>    Affects Versions: 2.0.0
>            Reporter: Andrew Purtell
>            Priority: Blocker
>             Fix For: 2.0.0
>
>
> There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation:
> - compactMob
> - compactMobs
> - majorCompactMob
> - majorCompactMobs
> - getMobCompactionState
> And in HBaseAdmin:
> - validateMobColumnFamily
> Remove these special cases from the Admin API where possible by folding them into existing APIs.
> We definitely don't need one method for a singleton and another for collections.
> Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features.
> Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)