[
https://issues.apache.org/jira/browse/HBASE-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-16225:
------------------------------
Description:
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.
was: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.
> Refactor ScanQueryMatcher
> -------------------------
>
> Key: HBASE-16225
> URL: https://issues.apache.org/jira/browse/HBASE-16225
> Project: HBase
> Issue Type: Improvement
> Reporter: Duo Zhang
>
> 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)
