[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100876#comment-14100876
]
Carter commented on HBASE-11657:
--------------------------------
That would certainly solve the problem with {{TableInputFormatBase}}. We
should also probably add a _getTableName_ method to {{RegionLocator}},
regardless. Then passing the RL interface instead of a raw HTable object would
provide everything that it needs for sharding the MR.
A more philosophical question is, why is {{HRegionLocation}}
InterfaceAudience.Private to begin with? It is a POJO that wraps
{{HRegionInfo}} (InterfaceAudience.Public), {{ServerName}}
(InterfaceAudience.Public), and _seqNum_ (an immutable long). It seems to me
that either the internal fields should be private too, or HRegionLocation
should be public. Unless there is some correlation of that information that
shouldn't be exposed. Thoughts, [~stack], [~ndimiduk], [~enis]?
> 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
>
> Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
> HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
>
>
> 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)
