Hi Shawn,
Thank you, I also had my suspicion on the sow parameter. but I can't figure
out why it is acting differently for analyzed type and non-analyzed.
for example, If I give this query to solr 8.7
fq=negativeattribute:(citychennai mcat43120
20mcat43120)&debug=query&fq=mcatid:(43120 26527 43015)
It parses both queries as you can see for mcatid field it is working like
sow is true.
"parsed_filter_queries": [
"negativeattribute:citychennai mcat43120 mcat43120",
"mcatid:43120 mcatid:26527 mcatid:43015"
]
}
Schema of negattribute field
<fieldType name="negattribute" class="solr.TextField" positionIncrementGap=
"100"> <analyzer type="index"> <tokenizer class="solr
.KeywordTokenizerFactory"/> <filter class="solr.LowerCaseFilterFactory"/> <
filter class="solr.TrimFilterFactory"/> </analyzer> <analyzer type="query">
<tokenizer class="solr.KeywordTokenizerFactory"/> <filter class="solr
.LowerCaseFilterFactory"/> <filter class="solr.TrimFilterFactory"/> </
analyzer> </fieldType>
Schema of mcatid field
<fieldType name="string" class="solr.StrField" sortMissingLast="true"
omitNorms="true"/>
On Wed, Jul 21, 2021 at 8:42 PM Shawn Heisey <[email protected]> wrote:
> On 7/20/2021 11:37 PM, Satya Nand wrote:
> > We have a filter query in our system
> > "fq=negativeattribute:(citychennai%20citydelhi)", in solr 6.5 it was
> > working fine. solr 6.5 parsed query as <arr
> > name="parsed_filter_queries"> <str>negativeattribute:citychennai
> > negativeattribute:citydelhi</str> </arr> After upgrading the solr to
> > 8.7, this query broke. It is not working as before solr 8.7 parsed
> > query as "parsed_filter_queries": [ "negativeattribute:citychennai
> > citydelhi", } Schema of negattribute field
>
> The "sow" query parameter (split on whitespace) now defaults to false.
> This is intentional. Your analysis chain doesn't split the input into
> tokens, so the value is accepted as-is -- with the space.
>
> It is expected that the query analysis definition will do the splitting
> now, not the query parser.
>
> You can add "sow=true" to the query parameters, either on the request or
> in the handler definition, and regain the behavior you're expecting.
> But if you actually do intend to have this field be an exact match of
> all characters including space, that's probably not the best idea. If
> you change the fq to the following, it would also work:
>
> fq=negativeattribute:(citychennai OR citydelhi)
>
> Thanks,
> Shawn
>
>
--
