[
https://issues.apache.org/jira/browse/HBASE-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393072#comment-15393072
]
Duo Zhang commented on HBASE-16225:
-----------------------------------
[~apurtell] [~stack] Any comments? Thanks.
And there are some topic to be discussed:
1. We should not pass delete marker to filter. A simple per cell filter can not
deal with delete marker well. A per row filter maybe enough on logic, but it
requires read a whole row always, this is not a good idea for compaction since
it may cause OOM. So I think if you want to deal with delete marker with
coprocessor when compaction, it is better to write a new scanner
implementation. And also, I suggest that we should disable filter for raw scan.
2. Define a determinate behavior of how thing will go on if you specific a
filter(maybe a new type which is called ServerFilter, as [~ghelmling] said
above) and a explicit column tracker when compaction. This helps us not
breaking coprocessor when modifying SQM(or that, give us the ability to modify
SQM...).
3. Is it correct to check filter before check version? I think this could also
make the disappear cell appear again?
And it is much easier to implement new stuffs on the refactored SQM than the
old big SQM. Thanks.
> Refactor ScanQueryMatcher
> -------------------------
>
> Key: HBASE-16225
> URL: https://issues.apache.org/jira/browse/HBASE-16225
> Project: HBase
> Issue Type: Improvement
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Attachments: HBASE-16225-v1.patch, HBASE-16225-v2.patch,
> HBASE-16225.patch
>
>
> As said in HBASE-16223, the code of {{ScanQueryMatcher}} is too complicated.
> I suggest that we can abstract an interface and implement several sub classes
> which separate different logic into different implementations. For example,
> the requirements of compaction and user scan are different, now we also need
> to consider the logic of user scan even if we only want to add a logic for
> compaction. And at least, the raw scan does not need a query matcher... we
> can implement a dummy query matcher for it.
> Suggestions are welcomed. Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
