Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 641A311C5F for ; Sat, 23 Aug 2014 18:20:13 +0000 (UTC) Received: (qmail 31914 invoked by uid 500); 23 Aug 2014 18:20:12 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 31869 invoked by uid 500); 23 Aug 2014 18:20:12 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 31731 invoked by uid 99); 23 Aug 2014 18:20:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Aug 2014 18:20:12 +0000 Date: Sat, 23 Aug 2014 18:20:12 +0000 (UTC) From: "Ted Yu (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-11803) Programming model for reverse scan is confusing MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-11803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14108081#comment-14108081 ] Ted Yu commented on HBASE-11803: -------------------------------- Adding ExclusiveStartFilter would benefit users who use reverse scan directly. Should I proceed with Andrew's plan in this JIRA ? > Programming model for reverse scan is confusing > ----------------------------------------------- > > Key: HBASE-11803 > URL: https://issues.apache.org/jira/browse/HBASE-11803 > Project: HBase > Issue Type: Bug > Components: Client > Affects Versions: 0.98.1 > Reporter: James Taylor > Assignee: Ted Yu > > The reverse scan is a very nice feature in HBase. We leverage it in Apache Phoenix 4.1 when possible and see a huge boost in performance over re-ordering the result set ourselves. > However, the way in which you have to adjust the start/stop key is confusing. Our use case is that we have a scan that needs to be done and we've calculated an inclusive start row and an exclusive stop row. This is the way region boundaries are which is convenient as they can easily be intersected against the scan stop/start row. When we use a reverse scan, we are forced to switch the start and stop row values of the scan *and* adjust the byte values from inclusive to exclusive and from exclusive to inclusive. The former is not too bad, as you can just add a zero byte, but the latter is problematic. You can decrease the last byte by one, but you need to add an indeterminate 0xFF bytes to ensure you're not including a row unintentionally. > IMHO, it would be much cleaner to just keep the start/stop row as is and just set call the Scan.setReversed(true) method. -- This message was sent by Atlassian JIRA (v6.2#6252)