hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duo Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
Date Wed, 26 Apr 2017 01:53:04 GMT

    [ 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

View raw message