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 Nick Hall <da...@gmail.com> on 2016/10/07 03:24:35 UTC

mm being ignored by edismax

Hello,

I'm working on upgrading a Solr installation from 4.0 to 6.2.1 and have
everything mostly working but have hit a snag. I kept the schema basically
the same, just made some minor changes to allow it to work with the new
version, but one of my queries is working differently with the new version
and I'm not sure why.

In version 4.0 when I do a query with edismax like:

"params":{
      "mm":"3",
      "debugQuery":"on",
      "indent":"on",
      "q":"string1 string2 string3 string4 string5",
      "qf":"vehicle_string_t^1",
      "wt":"json",
      "defType":"edismax"}},

I get the results I expect, and the debugQuery shows:

"rawquerystring":"string1 string2 string3 string4 string5",
    "querystring":"string1 string2 string3 string4 string5",
    "parsedquery":"+((DisjunctionMaxQuery((vehicle_string_t:\"string 1\"))
DisjunctionMaxQuery((vehicle_string_t:\"string 2\"))
DisjunctionMaxQuery((vehicle_string_t:\"string 3\"))
DisjunctionMaxQuery((vehicle_string_t:\"string 4\"))
DisjunctionMaxQuery((vehicle_string_t:\"string 5\")))~3)",
    "parsedquery_toString":"+(((vehicle_string_t:\"string 1\")
(vehicle_string_t:\"string 2\") (vehicle_string_t:\"string 3\")
(vehicle_string_t:\"string 4\") (vehicle_string_t:\"string 5\"))~3)",


But when I run the same query with version 6.2.1, debugQuery shows:

"rawquerystring":"string1 string2 string3 string4 string5",
    "querystring":"string1 string2 string3 string4 string5",
    "parsedquery":"(+(+DisjunctionMaxQuery((vehicle_string_t:\"string 1\"))
+DisjunctionMaxQuery((vehicle_string_t:\"string 2\"))
+DisjunctionMaxQuery((vehicle_string_t:\"string 3\"))
+DisjunctionMaxQuery((vehicle_string_t:\"string 4\"))
+DisjunctionMaxQuery((vehicle_string_t:\"string 5\"))))/no_coord",
    "parsedquery_toString":"+(+(vehicle_string_t:\"string 1\")
+(vehicle_string_t:\"string 2\") +(vehicle_string_t:\"string 3\")
+(vehicle_string_t:\"string 4\") +(vehicle_string_t:\"string 5\"))",


You can see that the key difference is that in version 4 it uses the "~3"
to indicate the mm, but in 6.2.1 it doesn't matter what I have mm set to,
it always ends with "/no_coord" and is trying to match all 5 strings even
if mm is set to 1, so mm is being completely ignored.

I imagine there is some behavior that changed between 4 and 6.2.1 that I
need to adjust something in my configuration to account for, but I'm
scratching my head right now. Has anyone else seen this and can point me in
the right direction? Thanks,

Nick

Re: mm being ignored by edismax

Posted by Nick Hall <da...@gmail.com>.
Thanks. I read through this discussion and got it to work by setting
q.op=OR when mm is set, and then it worked as it previously did.

I have two suggestions that may clarify things a little going forward.
First, as I read the documentation it does not seem clear to me that q.op
is intended to be used with the edismax (or dismax) query parsers. The
"common query parameters" page: https://cwiki.apache.
org/confluence/display/solr/Common+Query+Parameters does not list q.op as a
parameter. This parameter is listed on the "standard query parameters"
page: https://cwiki.apache.org/confluence/display/solr/
The+Standard+Query+Parser but not in the dismax page: https://cwiki.apache.
org/confluence/display/solr/The+DisMax+Query+Parser. For clarity it seems
like q.op should be added to the dismax page with a note about how its
behavior relates to mm?

Also, I use the Solr web interface to do test queries while debugging. This
web interface has no field for q.op as far as I can see, so with (e)dismax
the mm field does not work effectively with the web interface.

Thank you for your help,
Nick


On Thu, Oct 6, 2016 at 10:53 PM, Alexandre Rafalovitch <ar...@gmail.com>
wrote:

> I think it is the change in the OR and AND treatment that had been
> confusing a number of people. There were discussions before on the
> mailing list about it, for example
> http://search-lucene.com/m/eHNlzBMAHdfxcv1
>
> Regards,
>    Alex.
> ----
> Solr Example reading group is starting November 2016, join us at
> http://j.mp/SolrERG
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
>
>
> On 7 October 2016 at 10:24, Nick Hall <da...@gmail.com> wrote:
> > Hello,
> >
> > I'm working on upgrading a Solr installation from 4.0 to 6.2.1 and have
> > everything mostly working but have hit a snag. I kept the schema
> basically
> > the same, just made some minor changes to allow it to work with the new
> > version, but one of my queries is working differently with the new
> version
> > and I'm not sure why.
> >
> > In version 4.0 when I do a query with edismax like:
> >
> > "params":{
> >       "mm":"3",
> >       "debugQuery":"on",
> >       "indent":"on",
> >       "q":"string1 string2 string3 string4 string5",
> >       "qf":"vehicle_string_t^1",
> >       "wt":"json",
> >       "defType":"edismax"}},
> >
> > I get the results I expect, and the debugQuery shows:
> >
> > "rawquerystring":"string1 string2 string3 string4 string5",
> >     "querystring":"string1 string2 string3 string4 string5",
> >     "parsedquery":"+((DisjunctionMaxQuery((vehicle_string_t:\"string
> 1\"))
> > DisjunctionMaxQuery((vehicle_string_t:\"string 2\"))
> > DisjunctionMaxQuery((vehicle_string_t:\"string 3\"))
> > DisjunctionMaxQuery((vehicle_string_t:\"string 4\"))
> > DisjunctionMaxQuery((vehicle_string_t:\"string 5\")))~3)",
> >     "parsedquery_toString":"+(((vehicle_string_t:\"string 1\")
> > (vehicle_string_t:\"string 2\") (vehicle_string_t:\"string 3\")
> > (vehicle_string_t:\"string 4\") (vehicle_string_t:\"string 5\"))~3)",
> >
> >
> > But when I run the same query with version 6.2.1, debugQuery shows:
> >
> > "rawquerystring":"string1 string2 string3 string4 string5",
> >     "querystring":"string1 string2 string3 string4 string5",
> >     "parsedquery":"(+(+DisjunctionMaxQuery((vehicle_string_t:\"string
> 1\"))
> > +DisjunctionMaxQuery((vehicle_string_t:\"string 2\"))
> > +DisjunctionMaxQuery((vehicle_string_t:\"string 3\"))
> > +DisjunctionMaxQuery((vehicle_string_t:\"string 4\"))
> > +DisjunctionMaxQuery((vehicle_string_t:\"string 5\"))))/no_coord",
> >     "parsedquery_toString":"+(+(vehicle_string_t:\"string 1\")
> > +(vehicle_string_t:\"string 2\") +(vehicle_string_t:\"string 3\")
> > +(vehicle_string_t:\"string 4\") +(vehicle_string_t:\"string 5\"))",
> >
> >
> > You can see that the key difference is that in version 4 it uses the "~3"
> > to indicate the mm, but in 6.2.1 it doesn't matter what I have mm set to,
> > it always ends with "/no_coord" and is trying to match all 5 strings even
> > if mm is set to 1, so mm is being completely ignored.
> >
> > I imagine there is some behavior that changed between 4 and 6.2.1 that I
> > need to adjust something in my configuration to account for, but I'm
> > scratching my head right now. Has anyone else seen this and can point me
> in
> > the right direction? Thanks,
> >
> > Nick
>

Re: mm being ignored by edismax

Posted by Alexandre Rafalovitch <ar...@gmail.com>.
I think it is the change in the OR and AND treatment that had been
confusing a number of people. There were discussions before on the
mailing list about it, for example
http://search-lucene.com/m/eHNlzBMAHdfxcv1

Regards,
   Alex.
----
Solr Example reading group is starting November 2016, join us at
http://j.mp/SolrERG
Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 7 October 2016 at 10:24, Nick Hall <da...@gmail.com> wrote:
> Hello,
>
> I'm working on upgrading a Solr installation from 4.0 to 6.2.1 and have
> everything mostly working but have hit a snag. I kept the schema basically
> the same, just made some minor changes to allow it to work with the new
> version, but one of my queries is working differently with the new version
> and I'm not sure why.
>
> In version 4.0 when I do a query with edismax like:
>
> "params":{
>       "mm":"3",
>       "debugQuery":"on",
>       "indent":"on",
>       "q":"string1 string2 string3 string4 string5",
>       "qf":"vehicle_string_t^1",
>       "wt":"json",
>       "defType":"edismax"}},
>
> I get the results I expect, and the debugQuery shows:
>
> "rawquerystring":"string1 string2 string3 string4 string5",
>     "querystring":"string1 string2 string3 string4 string5",
>     "parsedquery":"+((DisjunctionMaxQuery((vehicle_string_t:\"string 1\"))
> DisjunctionMaxQuery((vehicle_string_t:\"string 2\"))
> DisjunctionMaxQuery((vehicle_string_t:\"string 3\"))
> DisjunctionMaxQuery((vehicle_string_t:\"string 4\"))
> DisjunctionMaxQuery((vehicle_string_t:\"string 5\")))~3)",
>     "parsedquery_toString":"+(((vehicle_string_t:\"string 1\")
> (vehicle_string_t:\"string 2\") (vehicle_string_t:\"string 3\")
> (vehicle_string_t:\"string 4\") (vehicle_string_t:\"string 5\"))~3)",
>
>
> But when I run the same query with version 6.2.1, debugQuery shows:
>
> "rawquerystring":"string1 string2 string3 string4 string5",
>     "querystring":"string1 string2 string3 string4 string5",
>     "parsedquery":"(+(+DisjunctionMaxQuery((vehicle_string_t:\"string 1\"))
> +DisjunctionMaxQuery((vehicle_string_t:\"string 2\"))
> +DisjunctionMaxQuery((vehicle_string_t:\"string 3\"))
> +DisjunctionMaxQuery((vehicle_string_t:\"string 4\"))
> +DisjunctionMaxQuery((vehicle_string_t:\"string 5\"))))/no_coord",
>     "parsedquery_toString":"+(+(vehicle_string_t:\"string 1\")
> +(vehicle_string_t:\"string 2\") +(vehicle_string_t:\"string 3\")
> +(vehicle_string_t:\"string 4\") +(vehicle_string_t:\"string 5\"))",
>
>
> You can see that the key difference is that in version 4 it uses the "~3"
> to indicate the mm, but in 6.2.1 it doesn't matter what I have mm set to,
> it always ends with "/no_coord" and is trying to match all 5 strings even
> if mm is set to 1, so mm is being completely ignored.
>
> I imagine there is some behavior that changed between 4 and 6.2.1 that I
> need to adjust something in my configuration to account for, but I'm
> scratching my head right now. Has anyone else seen this and can point me in
> the right direction? Thanks,
>
> Nick