I think you are hitting this bug https://issues.apache.org/jira/browse/SOLR-12779
Jan > 29. apr. 2021 kl. 08:51 skrev Ere Maijala <ere.maij...@helsinki.fi>: > > Hello Markus, > > Thanks for the reply. I'm not sure I understand. The docs state the following: > > "The default value of mm is 0% (all clauses optional), unless q.op is > specified as "AND", in which case mm defaults to 100% (all clauses required)." > (https://solr.apache.org/guide/8_8/the-dismax-query-parser.html#TheDisMaxQueryParser-Themm_MinimumShouldMatch_Parameter) > > And obviously it has effect. You can also replace q.op=AND with mm=100%25 in > my examples with the same results. The multi-word synonym makes the query > explained by debugQuery=true seem wrong to me in that it requires all terms > to match in the same field, whereas normally the match can be found in any of > the fields listed in qf. For example this is the query from my first example: > > +(+DisjunctionMaxQuery((name:corsair | manu:corsair | cat:corsair)) > +DisjunctionMaxQuery((name:microsystems | manu:microsystems | > cat:microsystems)) +DisjunctionMaxQuery((name:memory | manu:memory | > cat:memory))) > > Using the synonym instead of `corsair microsystems` produces this: > > +(+((+name:corsair +name:microsystems +name:memory) | (+manu:corsair > +manu:microsystems +manu:memory) | (+cat:cmi +cat:memory))) > > We don't use stopwords. mm.autoRelax does not make a difference here. > > Best, > Ere > > Markus Jelsma kirjoitti 28.4.2021 klo 16.20: >> Hello Ere, >> The q.op parameter is not a dismax parameter. instead i think you are being >> bitten bij de mm parameter [1] which by default is 100%, meaning all terms >> must match. Multi word synonym handing and mm are not a very intuitive >> match, and can lead to crazy problems. Also beware of mm and stopword >> handling and check out mm.autoRelax [2]. But it is best not to use >> stopwords at all. >> Check it out, >> Markus >> [1] https://solr.apache.org/guide/6_6/the-dismax-query-parser.html >> [2] https://solr.apache.org/guide/6_6/the-extended-dismax-query-parser.html >> Op wo 28 apr. 2021 om 15:02 schreef Ere Maijala <ere.maij...@helsinki.fi>: >>> Hi, >>> >>> Here's one that I can't wrap my head around. The main question is: why >>> are the search terms treated differently in eDisMax if the query expands >>> to a multi-word synonym, and there are different field types and q.op=AND? >>> >>> This gets complicated quickly, so I tried to reproduce the results with >>> the techproducts example: >>> >>> 1. Start with vanilla Solr 8.8.2 >>> >>> 2. echo "cor => Corsair" >> >>> server/solr/configsets/sample_techproducts_configs/conf/synonyms.txt >>> >>> 4. echo "cmi => Corsair Microsystems" >> >>> server/solr/configsets/sample_techproducts_configs/conf/synonyms.txt >>> >>> 4. bin/solr start -e techproducts >>> >>> >>> Now, a basic query that works fine produces 2 results: >>> >>> >>> http://localhost:8983/solr/techproducts/select?q=corsair+microsystems+memory&debugQuery=true&defType=edismax&qf=name+manu+cat&q.op=AND >>> >>> But if I use the synonym, I don't get any results: >>> >>> >>> http://localhost:8983/solr/techproducts/select?q=cmi+memory&debugQuery=true&defType=edismax&qf=name+manu+cat&q.op=AND >>> >>> If I leave cat field out, however, I get 2 results: >>> >>> >>> http://localhost:8983/solr/techproducts/select?q=cmi+memory&debugQuery=true&defType=edismax&qf=name+manu&q.op=AND >>> >>> Also if leave q.op out and add AND between the terms, I get 2 results >>> even with the cat field: >>> >>> >>> http://localhost:8983/solr/techproducts/select?q=cmi+AND+memory&debugQuery=true&defType=edismax&qf=name+manu+cat >>> >>> The single-word synonym works just fine: >>> >>> >>> http://localhost:8983/solr/techproducts/select?q=cor+memory&debugQuery=true&defType=edismax&qf=name+manu+cat&q.op=AND >>> >>> >>> Can anyone shine a light on what's happening here? >>> >>> Additional notes: >>> >>> 1. This is a simplified example, and the real-world case is much more >>> complicated. It has our custom class create the synonyms for compound >>> words in Finnish, and the queries come from users. >>> >>> 2. As far as I can see mm doesn't affect the results in any meaningful >>> way, but I just might be doing something wrong. >>> >>> 3. I included the debugQuery parameter so that it's easy to see how >>> different the queries become. >>> >>> Best Regards, >>> Ere >>> >>> -- >>> Ere Maijala >>> Kansalliskirjasto / The National Library of Finland >>> > > -- > Ere Maijala > Kansalliskirjasto / The National Library of Finland
