Hi Bernd,
I was referring to assessing 5.5's behaviour based on a comparison to 4.10
when giving it that same inputs and configuration. Maybe I am wrong, and I
apologise if so. I am only seeing fragments of the situation each time, so
it is hard to be sure. Certainly in this case it looks like a case of 'mm'
set to 100% in this example, but I am basing that of previous emails about
your config.
Since you seem to comfortable moving the code around, might I suggest you
try looking in the TestExtendedDismaxParser class? It is a nice, portable
way of demonstrating the behaviour you believe is wrong. You can put some
fake documents at the top in the index() method, then add a new test method
(copy one of the existing ones like testDefaultOperatorWithMm() ) to show
the config that is behaving strangely with a query.
If there is something strange going on we should be able to get to the
bottom of it with some reproduction steps.
Ta,
Greg
On 15 September 2016 at 16:28, Bernd Fehling <bernd.fehl...@uni-bielefeld.de
> wrote:
> Your statement "using the old behaviour as a baseline for checking the
> correctness of 5.5 behaviour" might be a point of view.
>
> Let me give an example, my query:
> q=(text:(star AND trek AND wars)^200 OR text:("star trek wars")^350)
> results to 159 hits from 99 million records in the index (version 4.10.4).
> I checked all 159 hits, they are correct.
>
> The same query to the same indexed content build with 5.5.3 and also
> having 99 million records results in 0 (zero) hits.
>
> What do you think about this result?
>
> By the way, after copying ExtendedDismaxQParser from 4.10.4 to 5.5.3 I get
> now 137 hits. I really don't care about the difference, but at least
> I get some hits out of 99 million records and they are correct.
>
> Regards,
> Bernd
>
>
> Am 15.09.2016 um 01:41 schrieb Greg Pendlebury:
> > I'm sorry that's been your experience Bernd. If you do manage to find
> some
> > time it would be good to see some details on these bugs. It looks at the
> > moment as though this is a matter of perception when using the old
> > behaviour as a baseline for checking the correctness of 5.5 behaviour.
> >
> > Ta,
> > Greg
> >
> >
> > On 15 September 2016 at 01:27, Erick Erickson <erickerick...@gmail.com>
> > wrote:
> >
> >> Perhaps https://issues.apache.org/jira/browse/SOLR-8812 and related?
> >>
> >> Best,
> >> Erick
> >>
> >> On Tue, Sep 13, 2016 at 11:37 PM, Bernd Fehling
> >> <bernd.fehl...@uni-bielefeld.de> wrote:
> >>> Hi Greg,
> >>>
> >>> after trying several hours with all combinations of parameters and not
> >>> getting any useful search result with complex search terms and edismax
> >>> I finally copied o.a.s.s.ExtendedDismaxQParser.java from version
> 4.10.4
> >>> to 5.5.3 and did a little modification in o.a.s.u.SolrPluginUtils.java.
> >>>
> >>> Now it is searching correct and getting logical and valid search
> results
> >>> with any kind of complex search.
> >>> Problem solved.
> >>>
> >>> But still, the edismax, at least of 5.5.3, has some bugs.
> >>> If I get time I will look into this but right now my problem is solved
> >>> and the customers and users are happy.
> >>>
> >>> I hope that this buggy edismax version is not used in solr 6.x
> otherwise
> >> you
> >>> have the same problems there.
> >>>
> >>> Regards
> >>> Bernd
> >>>
> >>>
> >>> Am 12.09.2016 um 05:10 schrieb Greg Pendlebury:
> >>>> Hi Bernd,
> >>>>
> >>>> "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."
> >>>>
> >>>> It is correct in both cases. q.op dictates (for that query) what
> default
> >>>> operator to use when none is provided, and it is used as a priority
> over
> >>>> the system whole 'defaultOperator'. In either case, if you ask it to
> use
> >>>> OR, it uses it; if you ask it to use AND, it uses it. The behaviour
> from
> >>>> 4.10 that was changed (arguably fixed, although I know that is a
> >> debatable
> >>>> point) was that you asked it to use AND, and it ignored you
> >> (irrespective
> >>>> of whether you used defaultOperator or q.op). The are a few subtle
> >>>> distinctions that are being missed (like the difference between the
> >> boolean
> >>>> operators and the OCCURS flags that your are talking about), but they
> >> are
> >>>> not going to change the outcome.
> >>>>
> >>>> 8812 related to users who had been historically setting the q.op
> >> parameter
> >>>> to influence the downstream default selection of 'mm' (If you don't
> >> provide
> >>>> 'mm' it is set for you based on 'q.op') instead of directly setting
> the
> >>>> 'mm' value themselves. But again in this case, you're setting 'mm'
> >> anyway,
> >>>> so it shouldn't be relevant.
> >>>>
> >>>> Ta,
> >>>> Greg
> >>>>
> >>>> On 9 September 2016 at 16:44, Bernd Fehling <
> >> bernd.fehl...@uni-bielefeld.de>
> >>>> wrote:
> >>>>
> >>>>> 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
> >>>>>>>>
> >>>>>
> >>>>
> >>
> >
>
