[
https://issues.apache.org/jira/browse/HBASE-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379853#comment-15379853
]
Andrew Purtell commented on HBASE-16225:
----------------------------------------
I feel the pain [~Apache9]. That's why I made the suggestion above. It can take
so much time to make changes and not break critical functionality with an
evolutionary approach it could be more time effective to start over with a new
implementation. [~lhofhansl] has suggested in the past we do this cleanly using
a hierarchy of iterators and filters and this is indeed a clean and attractive
approach.
At any rate, if you do make progress and have an update, that will be great.
> 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)
