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
