[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13666248#comment-13666248
]
chunhui shen commented on HBASE-4811:
-------------------------------------
bq.ps: MVCC is checked by original seek(), which also be invoked in reverse
scan path, so here is safe
Yes, it's invoked, I see. What I'm worried is that the conflict between
seekBeforeRow and skipKVs by MVCC.
e.g Suppose the following keyvalues:
1.row1/c1:q1/
2.row2/c1:q1/
3.row3/c1:q1/
If the current peek of storeFileScanner is row2/c1:q1/, then call
seekBeforeRow("row2"), the scanner should be at "row1".
However, if 'row1' cann't be seen because of MVCC, skipKVs will cause scanner
at the position of "row2".
I'm not sure whether you have considered the above case, if so, that's great!
> Support reverse Scan
> --------------------
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
> Affects Versions: 0.20.6, 0.94.7
> Reporter: John Carrino
> Assignee: Liang Xie
> Attachments: HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv1.patch
>
>
> All the documentation I find about HBase says that if you want forward and
> reverse scans you should just build 2 tables and one be ascending and one
> descending. Is there a fundamental reason that HBase only supports forward
> Scan? It seems like a lot of extra space overhead and coding overhead (to
> keep them in sync) to support 2 tables.
> I am assuming this has been discussed before, but I can't find the
> discussions anywhere about it or why it would be infeasible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
