Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 478C5F17B for ; Fri, 5 Apr 2013 23:31:17 +0000 (UTC) Received: (qmail 30195 invoked by uid 500); 5 Apr 2013 23:31:16 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 30107 invoked by uid 500); 5 Apr 2013 23:31:16 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 30094 invoked by uid 99); 5 Apr 2013 23:31:16 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Apr 2013 23:31:16 +0000 Date: Fri, 5 Apr 2013 23:31:15 +0000 (UTC) From: "Varun Sharma (JIRA)" To: dev@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (HBASE-8284) Allow String Offset(s) in ColumnPaginationFilter for bookmark based pagination MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Varun Sharma created HBASE-8284: ----------------------------------- Summary: Allow String Offset(s) in ColumnPaginationFilter for bookmark based pagination Key: HBASE-8284 URL: https://issues.apache.org/jira/browse/HBASE-8284 Project: HBase Issue Type: Improvement Components: Filters Affects Versions: 0.94.6.1 Reporter: Varun Sharma Priority: Minor Fix For: 0.94.7 Attaching from email to HBase user mailing list: I am thinking of adding a string offset to ColumnPaginationFilter. There are two reasons: 1) For deep pagination, you can seek using SEEK_NEXT_USING_HINT. 2) For correctness reasons, this approach is better if the list of columns is mutation. Lets say you get 1st 50 columns using the current approach. In the mean time some columns are inserted amongst the 1st 50 columns. Now you request the 2nd set of 50 columns. Chances are that you will have duplicates amongst the 2 sets (1st 50 and 2nd 50). If instead you used the last column of the 1st 50 as a string offset for getting the 2nd set of columns, the chances of getting dups is significantly lower. This becomes important for user facing interactive applications. Particularly where consistency etc. are not as important since those are best effort services. But showing duplicates across pages is pretty bad. Please let me know if this makes sense and is feasible. Basically, I would like a string offset passed to ColumnPaginationFilter as an alternative constructor. If the string offset is supplied, then, I would like to seek to either the column supplied or if the column is deleted, seek to the column just greater than the supplied column. -- 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