lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Rowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-8531) QueryBuilder hard-codes inOrder=true for generated sloppy span near queries
Date Tue, 23 Oct 2018 16:21:00 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660913#comment-16660913
] 

Steve Rowe commented on LUCENE-8531:
------------------------------------

+1, thanks [~jim.ferenczi].

bq. (Multi)PhraseQuery-s allows some reordering but the semantic is different from an unordered
span near query.

Can you explain, or point to docs that explain what you mean?

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message