Thanks Show and Hoss. Just added lowercaseOperators=false to my edismax config and everything seems to be working.
*Thanks,* *Rajesh,* *(mobile) : 8328789519.* On Mon, Apr 27, 2015 at 11:53 AM, Rajesh Hazari <rajeshhaz...@gmail.com> wrote: > I did go through the documentation of edismax (solr 5.1 documentation), > that suggests to use "*stopwords"* query param that signal the parser to > respect stopfilterfactory while parsing, still i did not find this is > happening. > > my final query looks like this > > > http://host/solr/collection/select?q=term1+and+term2&sort=update_time+desc&rows=1&wt=json&indent=true&debugQuery=true&defType=edismax&stopwords=tru&group=true&group.ngroups=true&group.field=title&stopwords=true > > > "debug":{ > "rawquerystring":"term1 and term2", > "querystring":"term1 and term2", > "parsedquery":"(+(+DisjunctionMaxQuery((textSpell:term1)) > +DisjunctionMaxQuery((textSpell:term2))))/no_coord", > "parsedquery_toString":"+(+(textSpell:term1) +(textSpell:term2))", > "explain":{}, > "QParser":"ExtendedDismaxQParser",........... > > ...... > > Is this param introduced and supports from specific version of solr! > > our solr version is 4.7 and 4.9. > > > *Thanks,* > *Rajesh**.* > > On Sun, Apr 26, 2015 at 9:22 PM, Rajesh Hazari <rajeshhaz...@gmail.com> > wrote: > >> Thank you Hoss from correcting my understanding, again i missed this >> concept of edismax. >> >> Do we have any solrj class or helper to handle the scenario to pass on >> the query terms (by stripping stopwords ) to edismax using solrj api. >> for ex: if user queries for *"term1 and term2"* build and query to pass >> on this to edismax so that this user query will be parsed as >> >> >> *"parsedquery": "(+(DisjunctionMaxQuery((textSpell:term1) >> DisjunctionMaxQuery((textSpell:term2))))/no_coord" * >> >> *Thanks,* >> *Rajesh**.* >> >> On Fri, Apr 24, 2015 at 1:13 PM, Chris Hostetter < >> hossman_luc...@fucit.org> wrote: >> >>> >>> : I was under understanding that stopwords are filtered even before being >>> : parsed by search handler, i do have the filter in collection schema to >>> : filter stopwords and the analysis shows that this stopword is filtered >>> >>> Generally speaking, your understanding of the order of operations for >>> query parsing (regardless of hte parser) and analysis (regardless of the >>> fields/analyzers/filters/etc...) is backwards. >>> >>> >>> the query parser gets, as it's input, the query string (as a *single* >>> string) and the request params. it inspects/parses the string according >>> to it's rules & options & syntax and based on what it finds in that >>> string >>> (and in other request params) it passes some/all of that string to the >>> analyzer for one or more fields, and uses the results of those analyzers >>> as the terms for building up a query structure. >>> >>> ask yourself: if the raw user query input was first passed to an analyzer >>> (for stop word filtering as you suggest) before the being passed to the >>> query parser -- how would solr know what analyzer to use? in many >>> parsers >>> (like lucene and edismax) the fields to use can be specified *inside* the >>> query string itself >>> >>> likewise: how would you ensure that syntactically significant string >>> sequences (like "(" and ":" and "AND" etc..) that an analyzer might >>> normally strip out based on the tokenizer/tokenfilters would be preserved >>> so that the query parser could have them and use them to drive hte >>> resulting query structure? >>> >>> >>> >>> -Hoss >>> http://www.lucidworks.com/ >>> >> >> >
