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 gnandre <ar...@gmail.com> on 2020/09/22 23:44:58 UTC
Difference in q.op param behavior between Solr 6.3 and Solr 8.5.2
In 6.3, q.op param used to affect q as well fq param behavior. E.g. if q.op
is set to AND and fq is set to id:(1 2 3), no results will show up but if
it is set to OR then all 3 results will show up. This does not happen in
Solr 8.5.2 anymore.
Is this a bug? What does one need to do in Solr 8.5.2 to achieve the same
behavior besides passing the operator directly in fq param i.e. id:(1 OR 2
OR 3)
Re: Difference in q.op param behavior between Solr 6.3 and Solr 8.5.2
Posted by gnandre <ar...@gmail.com>.
Thanks, this is helpful. I agree. q.op param should not affect fq
parameter. I think this is a feature and not a bug.
On Wed, Sep 23, 2020 at 4:39 PM Erik Hatcher <er...@gmail.com> wrote:
> In 6.3 it did that? It shouldn't have. q and fq shouldn't share
> parameters. fq's themselves shouldn't, IMO, have global defaults. fq's
> need to be stable and often uniquely specified kinds of constraining query
> parsers ({!terms/term/field,etc}) or rely on basic Lucene query parser
> syntax and be able to stably rely on AND/OR.
>
> Relevancy tuning on q and friends, tweaking those parameters, shouldn't
> affect fq's, to say it a little differently.
>
> One can fq={!lucene q.op=AND}id:(1 2 3)
>
> Erik
>
>
> > On Sep 23, 2020, at 4:23 PM, gnandre <ar...@gmail.com> wrote:
> >
> > Is there a way to set default operator as AND for fq parameter in Solr
> > 8.5.2 now?
> >
> > On Tue, Sep 22, 2020 at 7:44 PM gnandre <ar...@gmail.com> wrote:
> >
> >> In 6.3, q.op param used to affect q as well fq param behavior. E.g. if
> >> q.op is set to AND and fq is set to id:(1 2 3), no results will show up
> but
> >> if it is set to OR then all 3 results will show up. This does not
> happen in
> >> Solr 8.5.2 anymore.
> >>
> >> Is this a bug? What does one need to do in Solr 8.5.2 to achieve the
> same
> >> behavior besides passing the operator directly in fq param i.e. id:(1
> OR 2
> >> OR 3)
> >>
>
>
Re: Difference in q.op param behavior between Solr 6.3 and Solr 8.5.2
Posted by Erik Hatcher <er...@gmail.com>.
In 6.3 it did that? It shouldn't have. q and fq shouldn't share parameters. fq's themselves shouldn't, IMO, have global defaults. fq's need to be stable and often uniquely specified kinds of constraining query parsers ({!terms/term/field,etc}) or rely on basic Lucene query parser syntax and be able to stably rely on AND/OR.
Relevancy tuning on q and friends, tweaking those parameters, shouldn't affect fq's, to say it a little differently.
One can fq={!lucene q.op=AND}id:(1 2 3)
Erik
> On Sep 23, 2020, at 4:23 PM, gnandre <ar...@gmail.com> wrote:
>
> Is there a way to set default operator as AND for fq parameter in Solr
> 8.5.2 now?
>
> On Tue, Sep 22, 2020 at 7:44 PM gnandre <ar...@gmail.com> wrote:
>
>> In 6.3, q.op param used to affect q as well fq param behavior. E.g. if
>> q.op is set to AND and fq is set to id:(1 2 3), no results will show up but
>> if it is set to OR then all 3 results will show up. This does not happen in
>> Solr 8.5.2 anymore.
>>
>> Is this a bug? What does one need to do in Solr 8.5.2 to achieve the same
>> behavior besides passing the operator directly in fq param i.e. id:(1 OR 2
>> OR 3)
>>
Re: Difference in q.op param behavior between Solr 6.3 and Solr 8.5.2
Posted by gnandre <ar...@gmail.com>.
Is there a way to set default operator as AND for fq parameter in Solr
8.5.2 now?
On Tue, Sep 22, 2020 at 7:44 PM gnandre <ar...@gmail.com> wrote:
> In 6.3, q.op param used to affect q as well fq param behavior. E.g. if
> q.op is set to AND and fq is set to id:(1 2 3), no results will show up but
> if it is set to OR then all 3 results will show up. This does not happen in
> Solr 8.5.2 anymore.
>
> Is this a bug? What does one need to do in Solr 8.5.2 to achieve the same
> behavior besides passing the operator directly in fq param i.e. id:(1 OR 2
> OR 3)
>