You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Bastien Latard | MDPI AG <la...@mdpi.com.INVALID> on 2016/08/05 06:34:02 UTC
Fwd: Re: How can I set the defaultOperator to be AND?
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
==> results for black AND white
The correct result should be the following (but I had to force the q.op):
==> 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 <ma...@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
>>
>>
Re: How can I set the defaultOperator to be AND?
Posted by Steve Rowe <sa...@gmail.com>.
Hi Bast,
Good to know you got it to work - thanks for letting us know!
--
Steve
www.lucidworks.com
> On Sep 2, 2016, at 4:30 AM, Bastien Latard | MDPI AG <la...@mdpi.com.INVALID> wrote:
>
> 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 <la...@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 <la...@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
>>>>>>
>>>>>>
>>>>>>
Re: How can I set the defaultOperator to be AND?
Posted by Bastien Latard | MDPI AG <la...@mdpi.com.INVALID>.
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
>>> <la...@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
>>>> <la...@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
>>>>>
>>>>>
>>>>>
Re: How can I set the defaultOperator to be AND?
Posted by Bastien Latard | MDPI AG <la...@mdpi.com.INVALID>.
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 <la...@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 <la...@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
>>>>
>>>>
>>>>
Re: How can I set the defaultOperator to be AND?
Posted by Steve Rowe <sa...@gmail.com>.
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 <la...@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 <la...@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
>>>
>>>
>>>
>