[
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: [email protected]
For additional commands, e-mail: [email protected]
