[
https://issues.apache.org/jira/browse/HBASE-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reassigned HBASE-11803:
------------------------------
Assignee: Ted Yu
Sounds like a plan.
I can come up with a patch if James is good with the proposal.
> Programming model for reverse scan is confusing
> -----------------------------------------------
>
> Key: HBASE-11803
> URL: https://issues.apache.org/jira/browse/HBASE-11803
> Project: HBase
> Issue Type: Bug
> Components: Client
> Affects Versions: 0.98.1
> Reporter: James Taylor
> Assignee: Ted Yu
>
> The reverse scan is a very nice feature in HBase. We leverage it in Apache
> Phoenix 4.1 when possible and see a huge boost in performance over
> re-ordering the result set ourselves.
> However, the way in which you have to adjust the start/stop key is confusing.
> Our use case is that we have a scan that needs to be done and we've
> calculated an inclusive start row and an exclusive stop row. This is the way
> region boundaries are which is convenient as they can easily be intersected
> against the scan stop/start row. When we use a reverse scan, we are forced to
> switch the start and stop row values of the scan *and* adjust the byte values
> from inclusive to exclusive and from exclusive to inclusive. The former is
> not too bad, as you can just add a zero byte, but the latter is problematic.
> You can decrease the last byte by one, but you need to add an indeterminate
> 0xFF bytes to ensure you're not including a row unintentionally.
> IMHO, it would be much cleaner to just keep the start/stop row as is and just
> set call the Scan.setReversed(true) method.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
