You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Amrit Sarkar (JIRA)" <ji...@apache.org> on 2018/09/18 17:39:00 UTC

[jira] [Updated] (SOLR-12779) Force field/term centric matching mode for multi-term synonyms with splitOnWhitespace=false

     [ https://issues.apache.org/jira/browse/SOLR-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amrit Sarkar updated SOLR-12779:
--------------------------------
    Summary: Force field/term centric matching mode for multi-term synonyms with splitOnWhitespace=false  (was: Force field/term centric mode for multi-term synonyms with splitOnWhitespace=false)

> Force field/term centric matching mode for multi-term synonyms with splitOnWhitespace=false
> -------------------------------------------------------------------------------------------
>
>                 Key: SOLR-12779
>                 URL: https://issues.apache.org/jira/browse/SOLR-12779
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: master (8.0)
>            Reporter: Amrit Sarkar
>            Priority: Major
>
> As Doug Turnbull pointed out on the solr-user mailing list: _http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3cCALG6HL8W_cPeXCYnVKs2eSpDsTtcZ8_RbcYqWr+ZPoXwU5APPQ@mail.gmail.com%3e_, (recommended reading, especially for his discussion of the limitations of the new sow=false request parameter), sow=false changes the queries edismax produces over multiple fields when any of the fields’ query-time analysis differs from the other fields’, e.g. if one field’s analyzer removes stopwords when another field’s doesn’t. In this case, rather than a dismax-query-per-whitespace-separated-term (edismax’s behavior when sow=true), a dismax query per field is produced. This can change results in general, but quite significantly when combined with the mm (min-should-match) request parameter: since min-should-match applies per field instead of per term, missing terms in one field’s analysis won’t disqualify docs from matching. E.g. query “Terminator 100” with request param “mm=100%” against both a title (text) field and a run_length (integer) field will result in the following queries:
> When sow=true:
> {code:java}
> +(DisjunctionMaxQuery((title:terminator)) DisjunctionMaxQuery((run_length:[100 TO 100] | title:100)))~2{code}
> When sow=false:
> {code:java}
> +DisjunctionMaxQuery((run_length:[100 TO 100] | ((title:terminator title:100)~2))){code}
> In the above scenario, when sow=true (and in versions of Solr before 6.5), “terminator” must appear in documents in order to produce a match. But when sow=false, a document can match if its run_length field is 100, even when the title does not contain “terminator”.
> It is good to have an option to force term centric or query-centric matching at query parsing; so that expected behavior can be achieved; discussed under http://lucene.472066.n3.nabble.com/Split-on-whitespace-parameter-doubt-td4404185.html.



--
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