[
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986024#comment-15986024
]
Lars Hofhansl commented on HBASE-17958:
---------------------------------------
bq. Can you imagine that, you call a seek on an InputStream, and the
InputStream may do nothing and still return the next byte to you and you need
to guess whether it really done the seek?
This is different. What you get from an InputStream does not have an id. Here
we do (the key of the Cell). An id that the ColumnTrackers later verifies again
anyway.
Anyway. The patch looks good, except for the potential extra compare for SKIPed
columns and/or rows.
> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> ----------------------------------------------------------------------------
>
> Key: HBASE-17958
> URL: https://issues.apache.org/jira/browse/HBASE-17958
> Project: HBase
> Issue Type: Bug
> Reporter: Guanghao Zhang
> Assignee: Guanghao Zhang
> Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch,
> HBASE-17958-v1.patch, HBASE-17958-v2.patch, HBASE-17958-v3.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count
> the columns's number. If pass a same column to this filter, the count result
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when
> optimize SEEK to SKIP.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
