hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chunhui shen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4811) Support reverse Scan
Date Wed, 12 Jun 2013 11:30:22 GMT

    [ https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681132#comment-13681132
] 

chunhui shen commented on HBASE-4811:
-------------------------------------

[~lhofhansl]
Thanks for the review.

bq.do we need NonReversedNonLazyKeyValueScanner? Could add "unsupported" implementations for
these methods to NonLazyKeyValueScanner.
Sure, we could. Should we need rename "NonLazyKeyValueScanner"? Or only add new annotate for
this class?

bq.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.
backwardSeek is not only called when setting up. For this point, I don't understand very much,
it would be better if you could update the patch as you think.

bq.It should either scan backwards or not?
It is indeed weird calling backwardSeek in the method of reseek since reseek means forward
seek. 

I would update the path with addressing the first and third point later
                
> 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

Mime
View raw message