[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706451#comment-14706451 ]
Jingcheng Du commented on HBASE-14227: -------------------------------------- Thanks [~chenheng]! Maybe too many details for a public client. Sorry for mislead in my previous comments. How about this? {noformat} /** * The compaction types. * {@code NORMAL} is for compaction in store files. * {@code MOB} is for mob. If it is used the compaction of mob files is triggered. **/ {noformat} [~anoopsamjohn], do you want to have a look and give some advice? Thanks. > 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 > Assignee: Heng Chen > Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch > > > 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)