[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681613#comment-13681613
]
Lars Hofhansl commented on HBASE-4811:
--------------------------------------
bq. Sure, we could. Should we need rename "NonLazyKeyValueScanner"? Or only add
new annotate for this class?
I'd just add the new signatures.
bq. backwardSeek is not only called when setting up
I was trying to say that:
# ReversedKeyValueHeap should not need backwardSeek, since all calls to
(re)seek, etc, call backwardSeek anyway.
# Only MemstoreScanner and StoreFileScanner should need an explicit
backwardSeek method. Is that not so? (as I said I probably missed something).
For a reversed scan we should get the following hierarchy:
ReversedRegionScanner -> ReversedKVHeap -> ReversedStoreScanner ->
ReversedKVHeap -> (MemstoreScanner|StoreFileScanner). Right?
ReversedStoreScanner could always do the right (backward) seeking when
(re)seek, etc, is called. The tricky parts of MemstoreScanner and
StoreFileScanner since they are create/cached per memstore/HFile.
So would: ReversedRegionScanner -> KVHelp -> RerversedStoreScanner ->
ReversedKVHeap -> (MemstoreScanner|StoreFileScanner) work?
The ReversedKVHeap would only be needed to deal with the specialness of
MemstoreScanner and StoreFileScanner.
> 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: 4811-trunk-v10.txt, 4811-trunk-v5.patch,
> HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.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
