This is a problem that we’ve noted too. This blog post discusses the underlying cause https://opensourceconnections.com/blog/2018/02/20/edismax-and-multiterm-synonyms-oddities/
Hope that helps On Wed, May 2, 2018 at 3:07 PM Chris Wilt <cw...@plimptonhills.com> wrote: > I began with a 7.2.1 solr instance using the techproducts sample data. > Next, I added "a" as a stopword (there were originally no stopwords). > > > > I tried two queries: "x a b" and "x b". > > Here is the raw query parameters: > q=x b&fl=id,score,price&sort=score desc&qf=name^0.75 manu cat^3.0 > features^10.0&defType=edismax > > > and > q=x a b&fl=id,score,price&sort=score desc&qf=name^0.75 manu cat^3.0 > features^10.0&defType=edismax > > > The idea is that I want different weights for the different fields, and I > want to be able to take the score of each term from its best field, i.e. > score the "x" from its match against the "cat" field and the "b" against > the "features" field. > > When I have "x b" I get this behavior exactly, with the parsed query as > follows: > +(((name:x)^0.75 | manu:x | (features:x)^10.0 | (cat:x)^3.0) > ((name:b)^0.75 | manu:b | (features:b)^10.0 | (cat:b)^3.0)) > > > When I use "x a b" I instead get: > +((name:x name:b)^0.75 | (manu:x manu:b) | (features:x features:b)^10.0 | > (cat:x cat:a cat:b)^3.0) > > > With the "x a b" query suppose document 1 matches "x" in "features" and > matches "b" in "cat". This document will get a single score based upon > either its "x" or its "b", but the score will not be the sum, as would have > been the case had the query been, "x b". > > > > > How do I get the edismax parser to behave the same for queries with > stopwords as it does without stopwords, keeping the behavior constant for > queries with no stopwords? > > > I tried using the stopwords parameter, but I get the same results with > that parameter taking the value of true or false. I also tried using the > tie parameter, but the tie parameter seem to change a max to a sum (it sums > up the scores of each field for each query term, rather than taking the max > of all fields for how well they match a query term). > -- CTO, OpenSource Connections Author, Relevant Search http://o19s.com/doug
