[
https://issues.apache.org/jira/browse/HBASE-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387513#comment-15387513
]
Duo Zhang commented on HBASE-16225:
-----------------------------------
The refactor is partially done.
https://github.com/Apache9/hbase/commit/eea2bbd5ae199a2e92f35354c9990514e04ee2a1
But I found a problem. I assume that, in compaction, we do not use filter, do
not specific columns, do not use TimeRange to filter out data... This makes the
logic much simpler.
But we have coprocessor, which could overwrite the existing {{Scanner}}, and
{{TestRegionObserverScannerOpenHook}} will fail since I just ignore the passed
in filter.
Personally, I do not think it is a good idea to make code complicated only
because coprocessor wants it to be complicated...
Thanks.
> 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)
