lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3041) Support Query Visting / Walking
Date Tue, 26 Apr 2011 10:04:03 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message