lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4517) Suggesters: allow to pass a user-defined predicate/filter to the completion searcher
Date Fri, 02 Nov 2012 14:59:12 GMT


Michael McCandless commented on LUCENE-4517:

Maybe, instead of pushing Predicate all the way down to TopNSearcher, since it already has
the acceptResult filtering, we could just pass it to the suggester and it consults the predicate?

Or maybe we add an acceptResult method to AnalyzingSuggester and the app can subclass &
override that?

I think to deal w/ the queue depth issue ... we should expose (expert) control over this,
eg make the queue depth "multiplier" a setter/ctor arg/protected member.  This way the app
that subclasses could also pass in a larger queue depth.
> Suggesters: allow to pass a user-defined predicate/filter to the completion searcher
> ------------------------------------------------------------------------------------
>                 Key: LUCENE-4517
>                 URL:
>             Project: Lucene - Core
>          Issue Type: New Feature
>            Reporter: Oliver Christ
>         Attachments: Lucene-trunk-20121026-AnalyzingSuggester.patch
> As a user, I'd like to be able to specify a
> filter during completion lookup which further determines whether some completion should
be considered or not. Assume, for example, that I have a suggestion engine for book titles.
In my current search, I'm only interested in computer science books, but I can't/don't want
to maintain separate WFSTs for each subject area. 
> Given some completion candidate, the filter would be called (with a key and/or the completion
string as a parameter) to determine whether or not the completion candidate should be added
to the result queue. 
> Note:
> Adding a filter/predicate to the AnalyzingSuggester is simple,
> as TopNSearcher<> already uses acceptResult() to test whether some completion should
be added - that can be overridden in a derived searcher class which simply calls the predicate.
Ideally the suggesters would access some kind of factory to instantiate the searcher to be
used (instead of hardwiring it in).
> *Discussion on java-user:*
> Mike McCandless:
> Exactly!  One gotchya is you have to be careful about the maxQueueDepth, because if your
acceptResult accepts too few results then the queue may have pruned away paths that would
have led to a valid topN path ...
> We may also invert all of these FST based suggests, and expose building blocks for apps
to build up custom suggesters.  There are many use cases we need to accommodate and we have
a ways to converge on a clear API here ...

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

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

View raw message