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] [Updated] (HBASE-16225) Refactor ScanQueryMatcher
Date Tue, 02 Aug 2016 06:09:21 GMT

     [ https://issues.apache.org/jira/browse/HBASE-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Duo Zhang updated HBASE-16225:
------------------------------
      Resolution: Fixed
    Hadoop Flags: Reviewed
          Status: Resolved  (was: Patch Available)

Pushed to master and branch-1.

Thanks all for reviewing.

> Refactor ScanQueryMatcher
> -------------------------
>
>                 Key: HBASE-16225
>                 URL: https://issues.apache.org/jira/browse/HBASE-16225
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver, Scanners
>    Affects Versions: 2.0.0, 1.4.0
>            Reporter: Duo Zhang
>            Assignee: Duo Zhang
>             Fix For: 2.0.0, 1.4.0
>
>         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)

Mime
View raw message