[
https://issues.apache.org/jira/browse/LUCENE-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025155#comment-13025155
]
Simon Willnauer commented on LUCENE-3041:
-----------------------------------------
Hey chris,
I have some comments on your patch:
* s/visitorClass/processorClass/
* s/visitor/processor/
* in InvocationDispatcher you might wanna check if the single parameter is
Query subclass
* I am worried about checking which method to dispatch for every query type
once per segment as well as that we create an processor instance per segment
and not per search. There are actually two problems here. 1. We create a new
instance per segment. 2. We can not share the dispatch map, not even across
segments. I think we should create one instance per search and pass the IR down
together with the query or even better follow the pattern that Collector et al.
uses and pass it with a setReader(IR) method. that way we also have a clear way
how to tell the processor that we just moved on to a new segment. Regarding
sharing the map, I think you should use a prototype pattern that creates a new
Processor from an existing one maybe via clone()? In the InvocationDispatcher
case we should maybe use a concurrent hash map and share the map across
instances for the same dispatcher class.
* The process implementation in DefaultQueryProcessor executes query.rewrite
before passing the query to the
dispatcher which is no good since some QueryProcessor impls might not want to
rewrite that query at all. In LUCENE-2868 karl tries to find a way to prevent
lucene to rewrite one and the same FuzzyQuery since he has them in multiple
clauses somewhere down the BQ tree. This is a super expensive operation in his
case to rewriting it only once makes sense. I think this should be left to the
actual implementation.
> Support Query Visting / Walking
> -------------------------------
>
> Key: LUCENE-3041
> URL: https://issues.apache.org/jira/browse/LUCENE-3041
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Chris Male
> Priority: Minor
> Attachments: LUCENE-3041.patch
>
>
> Out of the discussion in LUCENE-2868, it could be useful to add a generic
> Query Visitor / Walker that could be used for more advanced rewriting,
> optimizations or anything that requires state to be stored as each Query is
> visited.
> We could keep the interface very simple:
> {code}
> public interface QueryVisitor {
> Query visit(Query query);
> }
> {code}
> and then use a reflection based visitor like Earwin suggested, which would
> allow implementators to provide visit methods for just Querys that they are
> interested in.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
