You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Areek Zillur (JIRA)" <ji...@apache.org> on 2014/02/05 23:30:13 UTC
[jira] [Comment Edited] (LUCENE-5404) Add support to get number of
entries a Suggester Lookup was built with and minor refactorings
[ https://issues.apache.org/jira/browse/LUCENE-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13892656#comment-13892656 ]
Areek Zillur edited comment on LUCENE-5404 at 2/5/14 10:29 PM:
---------------------------------------------------------------
Thanks for the review Michael! I will commit this shortly if there are no further objections.
{quote}
I think maybe each suggester should just have its own lookup method, taking its additional params? Ie, I'm not sure how consistently each one will have options that the others would want to use. E.g. AnalyzingInfixSuggester accepts two additional booleans: allTermsRequired, doHighlight. But I don't think other suggesters can support these options...
{quote}
I am aware that all suggesters can not support all params but, it is the same idea behind InputIterator? (not all suggesters support payload or weight). So if this object has params set that is not supported by suggesters, the suggester can raise an exception? The way I see it:
{code}
Lookup suggester = ..;
LookupOptions lookupOptions = ...;
suggester.lookup(lookupOptions); // if lookupOptons set doHighlight but the suggester does not support it throw exception
{code}
is nicer than
{code}
Lookup suggester = ..;
if (suggester instanceof AnalyzingInfixSuggester)
((AnalyzingInfixSuggester) suggster).lookup("foo", 3, false, true);
else
suggester.lookup("foo", false, 3);
{code}
But this does add another level of 'abstraction'? This will allow for adding new params by suggesters and be used by just using the Lookup class. Just a thought.
was (Author: areek):
Thanks for the review Micheal! I will commit this shortly if there are no further objections.
{quote}
I think maybe each suggester should just have its own lookup method, taking its additional params? Ie, I'm not sure how consistently each one will have options that the others would want to use. E.g. AnalyzingInfixSuggester accepts two additional booleans: allTermsRequired, doHighlight. But I don't think other suggesters can support these options...
{quote}
I am aware that all suggesters can not support all params but, it is the same idea behind InputIterator? (not all suggesters support payload or weight). So if this object has params set that is not supported by suggesters, the suggester can raise an exception? The way I see it:
{code}
Lookup suggester = ..;
LookupOptions lookupOptions = ...;
suggester.lookup(lookupOptions); // if lookupOptons set doHighlight but the suggester does not support it throw exception
{code}
is nicer than
{code}
Lookup suggester = ..;
if (suggester instanceof AnalyzingInfixSuggester)
((AnalyzingInfixSuggester) suggster).lookup("foo", 3, false, true);
else
suggester.lookup("foo", false, 3);
{code}
But this does add another level of 'abstraction'? This will allow for adding new params by suggesters and be used by just using the Lookup class. Just a thought.
> Add support to get number of entries a Suggester Lookup was built with and minor refactorings
> ---------------------------------------------------------------------------------------------
>
> Key: LUCENE-5404
> URL: https://issues.apache.org/jira/browse/LUCENE-5404
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Reporter: Areek Zillur
> Fix For: 5.0, 4.7
>
> Attachments: LUCENE-5404.patch, LUCENE-5404.patch, LUCENE-5404.patch, LUCENE-5404.patch
>
>
> It would be nice to be able to tell the number of entries a suggester lookup was built with. This would let components using lookups to keep some stats regarding how many entries were used to build a lookup.
> Additionally, Dictionary could use InputIterator rather than the BytesRefIteratator, as most of the implmentations now use it.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org