lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajesh Hazari <>
Subject Re: and stopword in user query is being change to q.op=AND
Date Mon, 27 Apr 2015 15:53:58 GMT
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

my final query looks like this


    "rawquerystring":"term1 and term2",
    "querystring":"term1 and term2",
    "parsedquery_toString":"+(+(textSpell:term1) +(textSpell:term2))",


Is this param introduced and supports from specific version of solr!

our solr version is 4.7 and 4.9.


On Sun, Apr 26, 2015 at 9:22 PM, Rajesh Hazari <>

> 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 <
> > 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message