You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Rajesh Hazari <ra...@gmail.com> on 2015/05/08 21:28:54 UTC

Re: and stopword in user query is being change to q.op=AND

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 <ra...@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 <ra...@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_lucene@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/
>>>
>>
>>
>