lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3041) Support Query Visting / Walking
Date Sat, 30 Apr 2011 03:41:03 GMT


Chris Male commented on LUCENE-3041:

To follow up on Earwin's comments, I'm going to do the following:

- Leave Query#rewrite out of the walking process.  As Earwin said, rewrite provides vital
query optimization / conversion to primitive runnable queries.  Having this method on Query
is a good idea since user Queries can simply implement this method and move on.
- In a separate issue, add a RewriteState like concept which can be used for caching rewrites
like that suggested by Simon.  This will have a considerable performance improvement for people
doing lots of repeated FuzzyQuerys for example.
- Change my processing concept into a generic Walker<I, O> system, which can be used
for lots of things in Lucene.  Users can implement this Walker to do whatever they want (maybe
we can pry Earwin's walker based highlighter from him? :D)
- Overload IndexSearcher's methods to support passing in a Walker.  We need this, instead
of simply having the Walker external, because we really want to support per-segment Walking.

I'll make a patch for the stuff related to this issue shortly, and spin off the RewriteState

> Support Query Visting / Walking
> -------------------------------
>                 Key: LUCENE-3041
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Chris Male
>            Priority: Minor
>         Attachments: LUCENE-3041.patch, LUCENE-3041.patch, LUCENE-3041.patch, 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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message