Steve Rowe created LUCENE-8531:
----------------------------------
Summary: QueryBuilder hard-codes inOrder=true for generated sloppy
span near queries
Key: LUCENE-8531
URL: https://issues.apache.org/jira/browse/LUCENE-8531
Project: Lucene - Core
Issue Type: Bug
Components: core/queryparser
Reporter: Steve Rowe
Assignee: Steve Rowe
QueryBuilder.analyzeGraphPhrase() generates SpanNearQuery-s with passed-in
phraseSlop, but hard-codes inOrder ctor param as true.
Before multi-term synonym support and graph token streams introduced the
possibility of generating SpanNearQuery-s, QueryBuilder generated
(Multi)PhraseQuery-s, which always interpret slop as allowing reordering edits.
Solr's eDismax query parser generates phrase queries when its pf/pf2/pf3
params are specified, and when multi-term synonyms are used with a graph-aware
synonym filter, SpanNearQuery-s are generated that require clauses to be in
order; unlike with (Multi)PhraseQuery-s, reordering edits are not allowed, so
this is a kind of regression. See SOLR-12243 for edismax pf/pf2/pf3 context.
(Note that the patch on SOLR-12243 also addresses another problem that blocks
eDismax from generating queries *at all* under the above-described
circumstances.)
I propose adding a new analyzeGraphPhrase() method that allows configuration of
inOrder, which would allow eDismax to specify inOrder=false. The existing
analyzeGraphPhrase() method would remain with its hard-coded inOrder=true, so
existing client behavior would remain unchanged.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
