Re: Difference in q.op param behavior between Solr 6.3 and Solr 8.5.2
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 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 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 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
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 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 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
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 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) >
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)