[
https://issues.apache.org/jira/browse/SOLR-13080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724441#comment-16724441
]
Daniel Lowe commented on SOLR-13080:
------------------------------------
I attempted to come up with a failing test before posting this and failed to do
so. With unsorted input makeStringUnion seems to produce a non-deterministic,
non-minimal automaton (rather than a deterministic minimal automaton)... but it
still matches the intended terms. Additionally the time to build the automaton
was significantly greater than the time required to perform a sort then build
the automaton (obviously this wouldn't be true in the case where the input
terms were provided in sorted order). I guess strictly speaking that makes this
only a performance optimization.
The closest I can really get to a unit test is that with assertions enabled,
unsorted input and the method set to automaton, DaciukMihovAutomatonBuilder
should throw an assertion error!
> TermsQParserPlugin automaton method fails to sort input
> -------------------------------------------------------
>
> Key: SOLR-13080
> URL: https://issues.apache.org/jira/browse/SOLR-13080
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
> Affects Versions: 7.5
> Reporter: Daniel Lowe
> Priority: Minor
>
> The contract for Automata.makeStringUnion is that the input is sorted. As
> BytesRef implements Comparable. The simplest fix would probably to make
> Arrays.sort(bytesRefs);
> The first line of automaton's makeFilter method in TermsQParserPlugin.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
