lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Rowe <sar...@gmail.com>
Subject Re: How can I set the defaultOperator to be AND?
Date Fri, 05 Aug 2016 12:37:30 GMT
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