Hi,
We personally use dismax as a more basic search endpoint so that users who
are not aware for lucene syntax don't end up using special keywords or
chars. which might affect their search queries.
The switch between dismax and edismax is triggered by an advanced get param.
I imagine there might
Question in general for the community :
what is the dismax capable of doing that the edismax is not ?
Is it really necessary to keep both of them or the dismax could be
deprecated ?
Cheers
-
---
Alessandro Benedetti
Search Consultant, R&D Software Engineer, Director
Sease Ltd. -
Wouldn't all of this depend entirely on the tokenizers used? I was talking
about phrases in a multi-token sense.
Regardless, I still think there should be similarity between dismax and
edismax for the commonly parameters. (Either extend the edismax logic to
dismax or vice versa)
Regards,
Sam
On
That would make sense.
Multi-term synonyms get into a weird case too. Should the single-term
words that have multi-term synonyms expand out? Or should the multi-term
synonyms that have single-term synonyms contract down and count as only a
single clause for pf2 or pf3.
On Tue, May 29, 2018 at 1
I don't have any hard position on this, It's ok to not build a phrase boost
if the input query is 1 term and it remains one term after the analysis for
one of the pf fields.
But if the term produces multiple tokens after query time analysis, I do
believe that building a phrase boost should be the
I disagree that a phrase of 1-word is just a phrase. That is the core
difference between the qf and pf clauses. Qf is collecting the terms; pf
is boosting the combinations.
For queries where the original query phrase has only a single term in it,
then it might be a moot point, unless the clauses
In my opinion, given the definition of dismax and edismax query parsers, they
should behave the same for parameters in common.
To be a little bit extreme I don't think we need the dismax query parser at
all anymore ( in the the end edismax is only offering more than the dismax)
Finally, I do beli
Hi Andrea,
Yes, on further investigation I found -
https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/ExtendedDismaxQParser.java#L574
I also created a ticket to resolve these differences and have a uniform way
of handling
Hi Sam,
I noticed the same behaviour. Looking at the code it seems that it is
expected: the two classes (ExtendedDisMaxQParser and DisMaxQParser)
don't have a direct inheritance relationships and the methods which deal
with the PF parameter are different. Specifically, the
DismaxQParser.getPhr
