[
https://issues.apache.org/jira/browse/LUCENE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660880#comment-16660880
]
Michael Gibney commented on LUCENE-8531:
----------------------------------------
I recognize that this was a bug (in that using {{SpanNearQuery}} with
{{inOrder=true}} and {{slop > 0}} changed the behavior, rather than simply the
implementation, of the built query).
That said, there surely are potential use cases for the {{inOrder=true}}
behavior, which is supported by {{SpanNearQuery}} but not by
({{Multi)PhraseQuery}}. Would it be worth opening a new issue to consider
introducing the ability to specifically request construction of
{{SpanNearQuery}} and/or {{inOrder=true}} behavior? The work that went into
building {{SpanNearQuery}} for phrases (commit
[96e8f0a0afe|https://github.com/apache/lucene-solr/commit/96e8f0a0afeb68e2d07ec1dda362894f0b94333d])
is still useful and relevant, even if the result isn't backward-compatible for
the case where {{slop > 0}}.
> 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
> Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: LUCENE-8531.patch
>
>
> 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]
