[
https://issues.apache.org/jira/browse/LUCENE-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768112#comment-16768112
]
Alan Woodward commented on LUCENE-3041:
---------------------------------------
Time to wake this one up again, I think... Here's an updated patch with a
slightly different QueryVisitor implementation:
* the default Query implementation just calls QueryVisitor.visitLeaf(Query)
* queries that match on specific terms can call QueryVisitor.visitLeaf(Query,
Term)
* queries that match on sets of terms can call QueryVisitor.visitLeaf(Query,
String field, Supplier<Predicate<Term>>)
* descending through the tree is done using one of the getXVisitor(Query)
methods, all of which have sensible defaults (match, shouldMatch and filter
return `this`, nonMatching returns a NO_OP visitor)
The test demonstrates a number of use-cases:
* An extractTerms() equivalent
* An extractTerms() that also includes terms from non-matching subclauses
* Building a predicate that will check any term and see if it's required to
run the query - useful for highlighters using re-analysis
* A visitor that collects terms and assigns them weights if they've been
wrapped by a BoostQuery
* A term extractor that collects minimum sets of terms required for a document
to match, much like luwak's TermExtractor and QueryTree hierarchies.
> Support Query Visting / Walking
> -------------------------------
>
> Key: LUCENE-3041
> URL: https://issues.apache.org/jira/browse/LUCENE-3041
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Affects Versions: 4.0-ALPHA
> Reporter: Chris Male
> Assignee: Simon Willnauer
> Priority: Minor
> Fix For: 4.9, 6.0
>
> Attachments: LUCENE-3041.patch, LUCENE-3041.patch, 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 was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
