[ 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