[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700939#comment-14700939 ]
Jingcheng Du commented on HBASE-14227: -------------------------------------- I mean we'd better not compact the normal and mob cf together. I have a way to fold the compactMob into the existing APIs. As you know, the mob is stored in a dummy mob region (with a constant name). We can use the exiting APIs compactRegion and majorCompactRegion to do this. # If the region name is a mob region name, we do compaction of mob. # Otherwise do normal compaction. How about this? > 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)