[
https://issues.apache.org/jira/browse/LUCENE-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16164001#comment-16164001
]
Robert Muir commented on LUCENE-7968:
-------------------------------------
>From what I can tell, since the stuff going into the FST (analyzed form,
>costs) is still in-order in this case, nothing detected it.
The surface forms are stored in a big byte[], so by being out of order it means
suggester's results just come back in a bizarre order when there are ties on
both the analyzed form and costs (rather than in fact being sorted by surface
form).
E.G. if you used a stemmer and added both {{dog (cost=2)}} and {{dogs
(cost=2)}}, suggester might sometimes return {{dog}} first, other times
{{dogs}}.
> AnalyzingSuggester's comparator compares incorrectly
> ----------------------------------------------------
>
> Key: LUCENE-7968
> URL: https://issues.apache.org/jira/browse/LUCENE-7968
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-7968.patch
>
>
> Found by LUCENE-7966, but we should fix here separate.
> Currently the tie-break case of this comparator is buggy when
> {{hasPayloads=false}}, as it assigns *negative* lengths to the BytesRefs
> being compared. The current BytesRef.compareTo simply silently returns false
> in this case, hiding the bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
