lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky" <>
Subject Re: Combining q.op=AND with boost not working
Date Sat, 02 Mar 2013 17:30:44 GMT
To properly set the default query operator to be AND, edit the /select 
request handler and set q.op there, for example:

<requestHandler name="/select" class="solr.SearchHandler">
   <lst name="defaults">
     <str name="echoParams">explicit</str>
     <int name="rows">10</int>
     <str name="df">text</str>
     <str name="defType">edismax</str>
     <str name="q.op">AND</str>

If you want to override the default operator on a single request and it as a 
simple parameter:


If all you want to do is add a boost to that query, use either the &boost or 
the &bf parameter. The former gives a multiplicative boost, the latter gives 
an additive boost. For example:


OTOH, if you're trying to do something with nested queries, try explaining 
what you want to accomplish in simple plain English before diving too much 

-- Jack Krupansky
-----Original Message----- 
From: yaybjorn
Sent: Saturday, March 02, 2013 11:18 AM
Subject: Combining q.op=AND with boost not working


After upgrading to solar 4.0 I noticed that the search-default operator is
OR and not AND. I'm trying to use LocalParams to set the default as advised
in the documentation instead of in the Schema. Now, this works when I'm
experimenting with the q.op=AND alone, but when I'm trying to put in my
boost function, it suddenly stops working. The boost function forks fine
alone. In short, this is my urls:

*Operator Only*
(Works: 237303 hits)

*Boost only*
/select?q={!boost b=popularity}(woman+smile)/
(Works: 665149 hits, boost has effect)

*Operator and boost*
/select?q={!q.op=AND boost b=popularity}(woman+smile)/
(665149 hits; operator not working anymore, boost still has effect)

I've tried all sorts of ways of combining the two, but no luck so far. I've
simplified my search query a lot just to show the unexpected effect.

Does anyone have any idea of what's going on here? Should it not be pretty
straight forward to include two such important parameters in a search? What
is the recommended way of handling this?


View this message in context:
Sent from the Solr - User mailing list archive at 

View raw message