[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs

[Heng Chen (JIRA)]

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

Heng Chen commented on HBASE-14227:
-----------------------------------

{quote}
 So when we call compact whether the compaction has to happen for the ref CF or 
MOB CF or both?
{quote}

IMO when call {{Admin.compact(final TableName tableName) throws IOException;}}, 
 the compaction would happen for both MOB CF and Normal CF.

So we can check, if table has MOB CF,  it would compact on MOB CF after normal 
CF compaction. just like below

{code}
 if (isMobFamily(tableName, columnFamily)) {
      try {
        compactMob(tableName, columnFamily, major);
      } catch (InterruptedException e) {
        LOG.warn("Compact Mob family is interrupted!", e);
      }
    } else {
      // normal compaction
         ......

      //if not specify column family, and table has mob cf, we should request 
compact for it.
      if (columnFamily == null && isMobTable(tableName)) {
        try {
          compactMob(tableName, null, false);
        } catch (InterruptedException e) {
          throw new IOException(e);
        }
      }
    }
{code}

And when we call {{Admin.getCompactionState}},  we also do this check if table 
has mob cf.


Any concerns? 



> 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)