[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14101532#comment-14101532
]
Enis Soztutar commented on HBASE-11657:
---------------------------------------
bq. Sorry to open up this can of worms, but that's part of the fun of
retrofitting an interface.
Agreed. It is good exercise in API design.
bq. Make HRL public. It contains ServerName and HRegionInfo, which are both
required by the current implementation of TableInputFormatBase.
I think this should be ok.
bq. Return ServerName and region name in some new POJO
What we want to hide is not HRL per se, but the region name concept. In this
case, making HRL public seems better.
bq. Find a new way to do what TableInputFormatBase wants to accomplish
I think RegionSizeCalculator should be made to work over ranges similar to the
MR API, but it can be another jira. What I am afraid more is whether there
maybe more users of HRL (other than MR) that we do not know about. Since
InterfaceAudience is fairly recent and it is not a hard check, there may be a
lot of users depending on it. If this is the case (which I honestly do not
know), then we should better made HRL public and be done with it. For
RegionLocations, we may need an immutable version.
> 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)
