After some more testing it feels like the parsing in 5.5.3 is _really_ messed
up.
Query version 4.10.4:
<str name="rawquerystring">
(text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
</str>
<str name="querystring">
(text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
</str>
<str name="parsedquery">
(+(((+text:star +text:trek +text:war)^200.0) PhraseQuery(text:"star trek
war"^350.0)))/no_coord
</str>
<str name="parsedquery_toString">
+(((+text:star +text:trek +text:war)^200.0) text:"star trek war"^350.0)
</str>
Same query version 5.5.3:
<str name="rawquerystring">
(text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
</str>
<str name="querystring">
(text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
</str>
<str name="parsedquery">
(+((+text:star +text:trek +text:war^200.0 PhraseQuery(text:"star trek
war"))~2))/no_coord
</str>
<str name="parsedquery_toString">
+(((+text:star +text:trek +text:war)^200.0 text:"star trek war"^350.0)~2)
</str>
As you can see version 5.5.3 "parsedquery" is different to version 4.10.4.
And why is parsedquery different to parsedquery_toString in version 5.5.3?
Where is my second boost in "parsedquery" of 5.5.3?
Bernd
Am 09.09.2016 um 08:44 schrieb Bernd Fehling:
> Hi Greg,
>
> thanks a lot, thats it.
> After setting q.op to OR it works _nearly_ as before with 4.10.4.
>
> But how stupid this?
> I have in my schema <solrQueryParser defaultOperator="AND"/>
> and also had q.op to AND to make sure my default _is_ AND,
> meant as conjunction between terms.
> But now I have q.op to OR and defaultOperator in schema to AND
> to just get _nearly_ my old behavior back.
>
> schema has following comment:
> "... The default is OR, which is generally assumed so it is
> not a good idea to change it globally here. The "q.op" request
> parameter takes precedence over this. ..."
>
> What I don't understand is why they change some major internals
> and don't give any notice about how to keep old parsing behavior.
>
> From my point of view the old parsing behavior was correct.
> If searching for a term without operator it is always OR, otherwise
> you can add "+" or "-" to modify that. Now with q.op AND it is
> modified to "+" as a MUST.
>
> I still get some differences in search results between 4.10.4 and 5.5.3.
> What other side effects has this change of q.op from AND to OR in
> other parts of query handling, parsing and searching?
>
> Regards
> Bernd
>
> Am 09.09.2016 um 05:43 schrieb Greg Pendlebury:
>> I forgot to mention the tickets:
>> SOLR-2649 and SOLR-8812
>>
>> On 9 September 2016 at 13:38, Greg Pendlebury <greg.pendleb...@gmail.com>
>> wrote:
>>
>>> Under 4.10 q.op was ignored by the edismax parser and always forced to OR.
>>> 5.5 is looking at the q.op=AND you requested.
>>>
>>> There are also some changes to the default values selected for mm, but I
>>> doubt those apply here since you are setting it explicitly.
>>>
>>> On 8 September 2016 at 00:35, Mikhail Khludnev <m...@apache.org> wrote:
>>>
>>>> I suppose
>>>> <str name="parsedquery_toString">+((text:star text:trek)~2)</str>
>>>> and
>>>> <str name="parsedquery_toString">+(+text:star +text:trek)</str>
>>>> are equal. mm=2 is equal to +foo +bar
>>>>
>>>> On Wed, Sep 7, 2016 at 10:52 AM, Bernd Fehling <
>>>> bernd.fehl...@uni-bielefeld.de> wrote:
>>>>
>>>>> Hi list,
>>>>>
>>>>> while going from SOLR 4.10.4 to 5.5.3 I noticed a change in query
>>>> parsing.
>>>>> 4.10.4
>>>>> <str name="rawquerystring">text:star text:trek</str>
>>>>> <str name="querystring">text:star text:trek</str>
>>>>> <str name="parsedquery">(+((text:star text:trek)~2))/no_coord</str>
>>>>> <str name="parsedquery_toString">+((text:star text:trek)~2)</str>
>>>>>
>>>>> 5.5.3
>>>>> <str name="rawquerystring">text:star text:trek</str>
>>>>> <str name="querystring">text:star text:trek</str>
>>>>> <str name="parsedquery">(+(+text:star +text:trek))/no_coord</str>
>>>>> <str name="parsedquery_toString">+(+text:star +text:trek)</str>
>>>>>
>>>>> There are very many new features and changes between this two versions.
>>>>> It looks like a change in query parsing.
>>>>> Can someone point me to the solr or lucene jira about the changes?
>>>>> Or even give a hint how to get my "old" query parsing back?
>>>>>
>>>>> Regards
>>>>> Bernd
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sincerely yours
>>>> Mikhail Khludnev
>>>>
