[
https://issues.apache.org/jira/browse/HADOOP-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Duxbury updated HADOOP-2631:
----------------------------------
Attachment: 2631.patch
This patch seems to resolve the problem. It still breaks out of the scanner
loop when the table name doesn't match the table we're searching for, but it
also starts the scanner at the name of the table we're searching for instead of
EMPTY_START_ROW, which was causing rows for different tables to pop up first
and prematurely end the scan.
> [hbase] 2443 breaks HTable.getStartKeys when there is more than one table or
> table you are enumerating isn't the first table
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-2631
> URL: https://issues.apache.org/jira/browse/HADOOP-2631
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Attachments: 2631.patch
>
>
> Clint Morgan noticed that the current HTable#getStartKeys implementation
> isn't correct when there are more than one table, or the table you're trying
> to get the start keys of isn't the only table. I believe that the solution is
> making sure that the scanner starts at the key that should lead off your
> table. We should create a TestGetStartKeys test to verify this behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
