hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matteo Bertozzi (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14888) ClusterSchema: Add Namespace Operations
Date Tue, 05 Jan 2016 00:34:39 GMT

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

Matteo Bertozzi commented on HBASE-14888:
-----------------------------------------

in Admin you replaced the sync create/modify/delete namespace with an async version.
what we did for create/delete/.. table was adding a "createTableAsync()" method returning
the Future and keeping the "sync" method sync. the implementation in that was opAsync().get()
so basically in Admin we have two set of method the one with the suffix Async() that return
the future and are async and the other one without the suffix that are sync.

the getOperationType() was not supposed to be an enum. probably the name is wrong, but the
idea was more like a "operation user-friendly description". if you look the only use is in
getDescription(), and it was basically an helper to avoid to rewrite the full description
tableName + operationDesc.

where is the Future<ProcedureInfo> returned by the ClusterSchema gone?
I liked the fact to be able to create an instance of ClusterSchema and use it 
more or less like Admin. with future = clusterSchema.createNamespace(); future.get()
now I have to know about the ProcedureExecutor and use the procId returned to lookup the state/result,
but maybe it's ok.

The blockOnProcedure() is ok for now, the only thing is that you can probably use:
procExecutor.isFinished(procId) instead of doing that trick with getResultOrProcedure() pairs.

> ClusterSchema: Add Namespace Operations
> ---------------------------------------
>
>                 Key: HBASE-14888
>                 URL: https://issues.apache.org/jira/browse/HBASE-14888
>             Project: HBase
>          Issue Type: Sub-task
>          Components: API
>            Reporter: stack
>            Assignee: stack
>             Fix For: 2.0.0
>
>         Attachments: 0001-Add-in-a-ClusterSchema-Interface.-It-will-have-all-Av2.patch,
14888.patch, 14888.v8.txt, 14888v11.patch, 14888v12.patch, 14888v13.patch, 14888v14.patch,
14888v15.patch, 14888v16.patch, 14888v17.txt, 14888v18.patch, 14888v19.patch, 14888v20.patch,
14888v3.txt, 14888v4.txt, 14888v5.txt, 14888v6.txt, 14888v7.txt, 14888v9.txt
>
>
> Add in a ClusterSchema Interface. It will have all API for all cluster manipulation;
adding namespaces, tables, amending column families, etc. The idea is to gather up our mess
and put it all behind a tidy API that all works the same way whatever you changing returning
a Future to wait on and behind the scenes driving Procedures.
> This patch does namespace operations first.



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

Mime
View raw message