[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680867#comment-13680867
]
Lars Hofhansl commented on HBASE-4811:
--------------------------------------
v9/v10 is much nicer. Few comments:
* do we need NonReversedNonLazyKeyValueScanner? Could add "unsupported"
implementations for these methods to NonLazyKeyValueScanner.
* Instead of leaking backwardSeek and seekToLastRow out of the Reversed*
classes, should we have an initScan() (or maybe setup()) method on the scanners
that does the right thing? I.e. a ReversedScanner would do the
seekToLastRow/backwardSeek stuff, and a normal scanner would just seek.
* This: {code}
+ @Override
+ public synchronized boolean reseek(KeyValue kv) throws IOException {
+ checkReseek();
+ return heap.backwardSeek(kv);
+ }
{code} and this {code}
+ @Override
+ public boolean backwardSeek(KeyValue key) throws IOException {
+ checkReseek();
+ return this.heap.backwardSeek(key);
+ }
{code}
Is weird. It should either scan backwards or not? If we do what I suggested in
the previous point, we would not need this, I think.
That way only MemstoreScanner and StoreFileScanner would be special. And they
have to special, because they are opened ahead of time (well, at least
StoreFileScanner is).
Sorry for being pain in the ***.
> 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
