I am not sure whether it is a bug or not actually. I never really used dismax. Perhaps others can comment on that.
Regards, Alex. On Wed, 17 Apr 2019 at 09:59, Nicolas Franck <nicolas.fra...@ugent.be> wrote: > > Ok, thanks for your investigation ;-) That was quick. > > So you consider this as a bug, as it was fixed for edismax parser? > > I thought the parameter q.op only applied to the terms in de main > query (parameter "q"), making .. > > jakarta apache > > to be interpreted as > > +jakarta +apache > > when q.op = AND > > The documentation of bq at least describes it as an "optional" query that only > influences the score, not the result list. > > > > On 16 Apr 2019, at 23:59, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > > > > If you set q.op=OR (and not as 'AND' you defined in your config), you > > will see the difference between your last two queries. The second last > > one will show 6 items and the last one still 5. > > > > As is, with your custom config, booster query is added as one more > > clause in the search. q.op=ALL forces it to be a compulsory clause, > > rather than an optional (boosting one). > > > > FQ is always a forced compulsory clause. Maybe it accepts boosts, but > > all scores are ignored anyway (it is just 0 for fail and anything else > > for pass). > > > > Adding 'debug=all' into the query parameters (or defaults) would help > > you see that for yourself. > > > > But it does seem (in 7.2.1 I have here) that edismax seems to wrap > > both query parts in individual brackets. Maybe there was a bug that > > was fixed in eDismax only. No ideas there, except that most of the > > effort goes into eDismax these days rather than dismax. > > > > Regards, > > Alex > > P.s. My suggestion was actually to give the queries against STOCK > > examples. That would have made all these parameters explicit and more > > obvious. And perhaps would have allowed you to discover the minimum > > parameter set causing the issue without all those other qf and pf in > > the game. > > > > On Tue, 16 Apr 2019 at 16:13, Nicolas Franck <nicolas.fra...@ugent.be> > > wrote: > >> > >> I agree, but I thought my thread was lost in the long list of issues. > >> > >> I prepared a simple case for solr 8.0: > >> > >> basic_dismax_set/config: > >> > >> schema.xml and solrconfig.xml > >> > >> basic_dismax_set/data: > >> > >> records_pp.json > >> > >> Total 6 records: > >> > >> http://localhost:8983/solr/test/select?echoParams=all > >> > >> 5 records match format:book > >> > >> http://localhost:8983/solr/test/select?echoParams=all&q=format:book&defType=lucene > >> > >> and 1 format:film > >> > >> http://localhost:8983/solr/test/select?echoParams=all&q=format:film&defType=lucene > >> > >> But when I try this (defType is dismax) ..: > >> > >> http://localhost:8983/solr/test/select?echoParams=all&bq=format:book^2 > >> > >> the result list is filtered on format:book (total of 5 records) > >> > >> This url gives the same result by the way: > >> > >> http://localhost:8983/solr/test/select?echoParams=all&fq=format:book^2 > >> > >> while the character ^ isn't supposed to work in fq, right? > >> > >> The same result in both Solr 7.4.0 and Solr 8.0 > >> > >> Thanks in advance > >> >
