[
https://issues.apache.org/jira/browse/LUCENE-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Christ updated LUCENE-4517:
----------------------------------
Attachment: Lucene-trunk-20121026-AnalyzingSuggester.patch
*Attached* Lucene-trunk-20121026-AnalyzingSuggester.patch
Adds predicate evaluation to AnalyzingSuggester, but does not address the queue
pruning issue raised by Mike.
> Suggesters: allow to pass a user-defined predicate/filter to the completion
> searcher
> ------------------------------------------------------------------------------------
>
> Key: LUCENE-4517
> URL: https://issues.apache.org/jira/browse/LUCENE-4517
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
