Thanks Steve for your advice (i.e.: upgrade to Solr 6.2).
I finally had time to upgrade and can now use "&q.op=AND" together with
"&q=a OR b" and this works as expected.
I even defined the following line in the defaults settings in the
requestHandler, to overwrite the default behavior:
<str name="q.op">AND</str>
Issue fixed :)
Kind regards,
Bast
On 05/08/2016 14:57, Bastien Latard | MDPI AG wrote:
Hi Steve,
I read the thread you sent me (SOLR-8812) and it seems that the 6.1
includes this fix, as you said.
I will upgrade.
Thank you!
Kind regards,
Bast
On 05/08/2016 14:37, Steve Rowe wrote:
Hi Bastien,
Have you tried upgrading to 6.1? SOLR-8812, mentioned earlier in the
thread, was released with 6.1, and is directly aimed at fixing the
problem you are having in 6.0 (also a problem in 5.5): when mm is not
explicitly provided and the query contains explicit operators (except
for AND), edismax now sets mm=0.
--
Steve
www.lucidworks.com
On Aug 5, 2016, at 2:34 AM, Bastien Latard | MDPI AG
<lat...@mdpi.com.INVALID> wrote:
Hi Eric & others,
Is there any way to overwrite the default OP when we use edismax?
Because adding the following line to solrconfig.xml doesn't solve
the problem:
<solrQueryParser defaultOperator="AND"/>
(Then if I do "q=black OR white", this always gives the results for
"black AND white")
I did not find a way to define a default OP, which is automatically
overwritten by the AND/OR from a query.
Example - Debug: defaultOP in solrconfig = AND / q=a or b
<Mail Attachment.png>
==> results for black AND white
The correct result should be the following (but I had to force the
q.op):
<Mail Attachment.png>
==> I cannot do this in case I want to do "(a AND b) OR c"...
Kind regards,
Bastien
On 27/04/2016 05:30, Erick Erickson wrote:
Defaulting to "OR" has been the behavior since forever, so changing
the behavior now is just not going to happen. Making it fit a new
version of "correct" will change the behavior for every application
out there that has not specified the default behavior.
There's no a-priori reason to expect "more words to equal fewer
docs", I can just as easily argue that "more words should return
more docs". Which you expect depends on your mental model.
And providing the default op in your solrconfig.xml request
handlers allows you to implement whatever model your application
chooses...
Best,
Erick
On Mon, Apr 25, 2016 at 11:32 PM, Bastien Latard - MDPI AG
<lat...@mdpi.com.invalid> wrote:
Thank you Shawn, Jan and Georg for your answers.
Yes, it seems that if I simply remove the defaultOperator it works
well for "composed queries" like '(a:x AND b:y) OR c:z'.
But I think that the default Operator should/could be the AND.
Because when I add an extra search word, I expect that the results
get more accurate...
(It seems to be what google is also doing now)
| |
Otherwise, if you make a search and apply another filter (e.g.:
sort by publication date, facets, ...) , user can get the less
relevant item (only 1 word in 4 matches) in first position only
because of its date...
What do you think?
Kind regards,
Bastien
On 25/04/2016 14:53, Shawn Heisey wrote:
On 4/25/2016 6:39 AM, Bastien Latard - MDPI AG wrote:
Remember:
If I add the following line to the schema.xml, even if I do a search
'title:"test" OR author:"me"', it will returns documents matching
'title:"test" AND author:"me"':
<solrQueryParser defaultOperator="AND"/>
The settings in the schema for default field and default operator
were
deprecated a long time ago. I actually have no idea whether they are
even supported in newer Solr versions.
The q.op parameter controls the default operator, and the df
parameter
controls the default field. These can be set in the request handler
definition in solrconfig.xml -- usually in "defaults" but there
might be
reason to put them in "invariants" instead.
If you're using edismax, you'd be better off using the mm parameter
rather than the q.op parameter. The behavior you have described
above
sounds like a change in behavior (some call it a bug) introduced
in the
5.5 version:
https://issues.apache.org/jira/browse/SOLR-8812
If you are using edismax, I suspect that if you set mm=100%
instead of
q.op=AND (or the schema default operator) that the problem might
go away
... but I am not sure. Someone who is more familiar with SOLR-8812
probably should comment.
Thanks,
Shawn
