lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bastien Latard | MDPI AG <lat...@mdpi.com.INVALID>
Subject Re: How can I set the defaultOperator to be AND?
Date Fri, 05 Aug 2016 12:57:54 GMT
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 <latard@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 <latard@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
>>>>
>>>>
>>>>

Mime
View raw message