Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 12 Jun 2013 11:30:22 +0000 (UTC)
From: "chunhui shen (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12531831.1321556604011.103666.1371036622857@arcas>
In-Reply-To: <JIRA.12531831.1321556604011@arcas>
References: <JIRA.12531831.1321556604011@arcas>
Subject: [jira] [Commented] (HBASE-4811) Support reverse Scan
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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