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 <elyog...@elyograg.org> 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 > > --