[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084937#comment-14084937
]
Carter commented on HBASE-11657:
--------------------------------
Okay, these are the region-related methods I spot in Admin. I think these
should move to the third, new interface:
{code}
void closeRegion(final byte[] regionname, final String serverName)
boolean closeRegionWithEncodedRegionName(final String encodedRegionName, final
String serverName)
void closeRegion(final ServerName sn, final HRegionInfo hri)
List<HRegionInfo> getOnlineRegions(final ServerName sn)
void move(final byte[] encodedRegionName, final byte[] destServerName)
void assign(final byte[] regionName)
void unassign(final byte[] regionName, final boolean force)
void offline(final byte[] regionName)
boolean setBalancerRunning(final boolean on, final boolean synchronous)
boolean balancer()
void mergeRegions(final byte[] encodedNameOfRegionA, final byte[]
encodedNameOfRegionB, final boolean forcible)
void stopRegionServer(final String hostnamePort)
List<HRegionInfo> getTableRegions(final TableName tableName)
byte[][] rollHLogWriter(String serverName)
{code}
Then there are a bunch of methods that take _tableNameOrRegionName_ as a
parameter: (Suggestions?)
{code}
flush
compact
majorCompact
split
getCompactionState
{code}
There are also a handful of DDL methods that also do region-y things. For
example:
{code}
void createTable(HTableDescriptor desc, byte[] startKey, byte[] endKey, int
numRegions)
void createTable(final HTableDescriptor desc, byte[][] splitKeys)
{code}
And there are a handful of operational methods, which seem like they should be
in Admin, but are not DDL-related. I think these should stay in Admin:
{code}
ClusterStatus getClusterStatus()
void stopMaster()
void shutdown()
String[] getMasterCoprocessors()
CoprocessorRpcChannel coprocessorService()
void execProcedure(String signature, String instance, Map<String, String> props)
all the snapshot methods
the catalog janitor methods
{code}
Thoughts on the revised strawman?
> Put HTable region methods in an interface
> -----------------------------------------
>
> Key: HBASE-11657
> URL: https://issues.apache.org/jira/browse/HBASE-11657
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.99.0
> Reporter: Carter
> Assignee: Carter
> Fix For: 0.99.0
>
>
> Most of the HTable methods are now abstracted by HTableInterface, with the
> notable exception of the following methods that pertain to region metadata:
> {code}
> HRegionLocation getRegionLocation(final String row)
> HRegionLocation getRegionLocation(final byte [] row)
> HRegionLocation getRegionLocation(final byte [] row, boolean reload)
> byte [][] getStartKeys()
> byte[][] getEndKeys()
> Pair<byte[][],byte[][]> getStartEndKeys()
> void clearRegionCache()
> {code}
> and a default scope method which maybe should be bundled with the others:
> {code}
> List<RegionLocations> listRegionLocations()
> {code}
> Since the consensus seems to be that these would muddy HTableInterface with
> non-core functionality, where should it go? MapReduce looks up the region
> boundaries, so it needs to be exposed somewhere.
> Let me throw out a straw man to start the conversation. I propose:
> {code}
> org.apache.hadoop.hbase.client.HRegionInterface
> {code}
> Have HTable implement this interface. Also add these methods to HConnection:
> {code}
> HRegionInterface getTableRegion(TableName tableName)
> HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
> {code}
> [~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
