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

Lars Hofhansl commented on HBASE-6954:
--------------------------------------

As I pointed out on the mailing list, this is by design.
Here's a comment to that extend in ScanQueryMatcher.java:
{code}
    /**
     * Filters should be checked before checking column trackers. If we do
     * otherwise, as was previously being done, ColumnTracker may increment its
     * counter for even that KV which may be discarded later on by Filter. This
     * would lead to incorrect results in certain cases.
     */
{code}

There are cases where folks want filters before the version counting and cases 
where they want it after the version counting.
Can't have it both ways, unless we're adding mechanisms to have the filter 
decide.

I made an effort to do this in HBASE-5257, I can revive that if there is demand.

                
> Column-counting filters can accept multiple versions of a column
> ----------------------------------------------------------------
>
>                 Key: HBASE-6954
>                 URL: https://issues.apache.org/jira/browse/HBASE-6954
>             Project: HBase
>          Issue Type: Bug
>          Components: Filters
>            Reporter: Andrew Olson
>         Attachments: ColumnPaginationFilterTest.java
>
>
> It looks like the max version limit for a table or scanner is not applied to 
> disregard older versions, prior to counting columns within a 
> ColumnPaginationFilter or ColumnCountGetFilter. As a result, a Scan or Get 
> can ultimately retrieve fewer than the requested number of columns when there 
> is a sufficient number of existing columns to satisfy the request, if 
> multiple versions of a column have been added to a row.
> A minimal test case demonstrating this behavior is attached.
> The javadoc for Get mentions 'Only Filter.filterKeyValue(KeyValue) is called 
> AFTER all tests for ttl, column match, deletes and max versions have been 
> run.'; for these two filters this behavior does not appear to be true, as 
> flattening of multiple versions appears to occur after the filter has been 
> applied.

--
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

Reply via email to