[
https://issues.apache.org/jira/browse/HBASE-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632181#comment-13632181
]
Hadoop QA commented on HBASE-8284:
----------------------------------
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12578796/8284-trunk.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/5316//console
This message is automatically generated.
> 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
> Assignee: Varun Sharma
> Priority: Minor
> Fix For: 0.98.0, 0.94.8, 0.95.1
>
> Attachments: 8284-0.94.txt, 8284-0.94-v2.txt, 8284-0.95.txt,
> 8284-trunk.txt
>
>
> 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
