[
https://issues.apache.org/jira/browse/SOLR-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105887#comment-13105887
]
Dawid Weiss commented on SOLR-2762:
-----------------------------------
I will review it later today. The code is based on several assumptions to speed
things up (for example it assumes the fst yields sorted output). I will try to
write a failing test case first.
@cyclomatic complexity: the conditions inside loops are meant to
early-interrupt the search. That's where the gain is and it'll be hard to get
rid of in a clean way.
@min(10, num): I typically try to avoid overallocating buffers; if somebody
requests > 10 matches (unlikely?) then we will gracefully expand the buffers as
we go. Also: the point of doing this is so that somebody could request _all_
matches by passing Integer.MAX_VALUE which would otherwise cause an OOM.
> FSTLookup returns one less suggestion than it should when onlyMorePopular=true
> ------------------------------------------------------------------------------
>
> Key: SOLR-2762
> URL: https://issues.apache.org/jira/browse/SOLR-2762
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
> Affects Versions: 3.3
> Reporter: David Smiley
> Assignee: Dawid Weiss
> Priority: Minor
> Attachments: SOLR-2762_FSTLookup_off_by_one.patch
>
>
> I'm using the Suggester. When I switched from TSTLookup to FSTLookup, I
> noticed that it returned one fewer suggestion than what I asked for. I have
> spellcheck.onlyMorePopular=true; when I set it to false, I see the correct
> count. Another aspect of the bug is that this off-by-one bug only seems to
> occur when my suggestion has an exact match.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
