Simply add the lowecaserOperators=false parameter or add it to the
"defaults" section of the request handler in solrconfig, and then "and" will
not be treated as "AND".
The wiki is confusing - it shouldn't be advising you how to set the
parameter to achieve the default setting! Rather, it should tell you how to
override the default setting.
-- Jack Krupansky
-----Original Message-----
From: Ahmet Arslan
Sent: Wednesday, February 19, 2014 4:16 AM
To: solr-user@lucene.apache.org
Subject: Re: Weird behavior of stopwords in search query
Hi Samik,
Please see parameter of edismax.
https://cwiki.apache.org/confluence/display/solr/The+Extended+DisMax+Query+Parser
If lowercaseOperators=true then and is treated as AND. Also stopwords
parameter could be used.
Stopwords and edismax had issues (when mm=100%) in history. Not sure current
situation but you may need to apply same set of stopwords to all fields
listed in qf parameter. Even to string types. String type should be replaced
with KeywordTokenizer + StopwordFilter combo.
On Wednesday, February 19, 2014 7:48 AM, shamik <sham...@gmail.com> wrote:
Jack, thanks for the pointer. I should have checked this closely. I'm using
edismax and here's my qf entry :
<str name="qf">
id^10.0 cat^1.4 text^0.5 features^1.0 name^1.2 sku^1.5 manu^1.1
title^10.0 description^5.0 keywords^5.0 author^2.0 resourcename^1.0
</str>
As you can see, I was boosting id and cat which are of type string and of
course doesn't go through the stopwords filter. Removing them returned one
result which is based on AND operator.
The part what I'm not clear is how "and" is being treated even through its a
stopword and the default operator is OR. Shouldn't this be ignored ?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Weird-behavior-of-stopwords-in-search-query-tp4118156p4118188.html
Sent from the Solr - User mailing list archive at Nabble.com.
