[
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983994#comment-15983994
]
Duo Zhang commented on HBASE-17958:
-----------------------------------
I do not think so.
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? That's not natural. If you really want to do
this, do not call it seek please.
And I do not get your point, why this is the job of the tracker? It is also
strange that a ColumnTracker tells you that I have enough versions for this
column so please seek to the next column or I have done with this row please
seek to the next row, but you still pass the cells from the same column or same
row to me and let me do the skip job? I can imagine that this question will be
asked again and again by different people when they try to change the code in
this area...
> 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
>
> {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)
