You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Duo Zhang (JIRA)" <ji...@apache.org> on 2016/08/01 02:04:21 UTC

[jira] [Commented] (HBASE-16225) Refactor ScanQueryMatcher

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

Duo Zhang commented on HBASE-16225:
-----------------------------------

I test some of the UTs locally, some of them can not pass, but not sure if it relates to the patch. Let me dig.

> 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-branch-1-v1.patch, HBASE-16225-branch-1.patch, HBASE-16225-v1.patch, HBASE-16225-v2.patch, HBASE-16225-v3.patch, HBASE-16225-v4.patch, HBASE-16225-v5.patch, HBASE-16225-v6.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)