Thanks for the pointers. I suppose the first hurdle is to collect the
"wide variety of representative queries". :) But even a small set would
provide some indication of the impact, I think, so it wouldn't hurt to
start using a proper tool for it.
--Ere
Eric Pugh kirjoitti 29.4.2021 klo 14.53:
This is where having a really nice regression test across a wide variety of
representative queries comes in super helpful, to understand the impact of
changes not just on one query, but across all your queries. See
https://quepid.com/ or https://github.com/SeaseLtd/rated-ranking-evaluator for
Thanks for sharing your experience. We've been running sow=false until
now and got away with it as most searches hit a catch-all field. That
won't be the case in the long run anymore, so now I'm contemplating
switching back to sow=true. It's just a bit scary change to do at this
point since it
I struggled with something very similar today, which turned our search
model upside down as in Solr 8+ edismax uses sow=false by default and it
was true in Solr 6 (where we upgraded from),
but after adding this my handler things were back to normal.
On Thu, Apr 29, 2021 at 11:45 AM Ere Maijala
wr
Ah, yes, that seems to be the case. Thanks for the pointer! Also the
discussion is enlightening. It looks like there hasn't been much
happening in that bug so I'll need to consider any other options.
--Ere
Jan Høydahl kirjoitti 29.4.2021 klo 11.48:
I think you are hitting this bug
https://is
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 :
>
> 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), u
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-que
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 stop
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 wit
