Shawn,

Thank you for the reply.  The URL you gave was helpful and Smiley & Pugh even 
more so.  On Smiley & Pugh page 140, they indicate that mm=100% using dismax is 
analogous to Standard's "q.op=AND".  This is exactly what I need.

However...testing with these queries and edismax, I get different # of results:

q=Title:(life hope) AND Title:(life)&q.op=AND  (STANDARD Q.P.) - 1 result
q=Title:(life AND hope) AND Title:(life)&defType=edismax - 1 result
q=Title:(life hope) AND Title:(life)&defType=edismax&mm=100% - 285 results 
(ut-oh.  looks like the first 2 get OR'ed)

The dismax parser seems to behave as documented:

q=life hope life&defType=dismax&rows=0&qf=Title&mm=0% - 285 results (results 
are OR'ed as expected)
q=life hope life&defType=dismax&rows=0&qf=Title&mm=100% - 1 result (results are 
AND'ed as expected)

Unfortunately I need to be able to combine the use of "pf" with "key:value" 
syntax, wildcards, etc, so I need to use edismax, I think.

With a quick glance at ExtendedDismaxQParserPlugin, I'm finding...
 - MM is ignored if there are any of these operators in the query (OR NOT + -)  
... but AND is ok (line 227)
 - MM is ignored if the "parse" method did not return a "BooleanQuery" instance 
(line 244)
 - MM is used after all regardless of operators used in the query, so long as 
its a "BooleanQuery" (line 286)
 - The default MM value is "100%" if not specified in the query parameters 
(lines 241, 283)
Given the apparent contradiction here, my very quick analysis is surely missing 
something!  But if this is accurate, then the trick is to formulate the query 
in such a way so that "parse" returns an instance of "BooleanQuery", right?  

Any more advice anyone can give is appreciated!  For the client I'm responsible 
for, I'm just inserting explicit operators between all of the user's queries.  
But for the client I'm not responsible for I would love to have a workaround 
for the other developers!  I think they'd appreciate it...

James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311


-----Original Message-----
From: Shawn Heisey [mailto:s...@elyograg.org] 
Sent: Wednesday, December 22, 2010 4:08 PM
To: solr-user@lucene.apache.org
Subject: Re: edismax inconsistency -- AND/OR

On 12/22/2010 8:25 AM, Dyer, James wrote:
> I'm using SOLR 1.4.1 with SOLR-1553 applied (edismax query parser).  I'm 
> experiencing inconsistent behavior with terms grouped in parenthesis.  
> Sometimes they are AND'ed and sometimes OR'ed together.
>
> 1. q=Title:(life)&defType=edismax>  285 results
> 2. q=Title:(hope)&defType=edismax>  34 results
>
> 3. q=Title:(life AND hope)&defType=edismax>  1 result
> 4. q=Title:(life OR hope)&defType=edismax>  318 results
> 5. q=Title:(life hope)&defType=edismax>  1 result (life, hope are being 
> AND'ed together)
>
> 6. q=Title:(life AND hope) AND Title:(life)&defType=edismax>  1 result
> 7. q=Title:(life OR hope) AND Title:(life)&defType=edismax>  285 result
> 8. q=Title:(life hope) AND Title:(life)&defType=edismax>  285 results (life, 
> hope are being OR'ed together)
>
> See how in #5, the two terms get AND'ed, but by adding the additional 
> (nonsense) clause in #8, the first two terms get OR'ed .  Is this a feature 
> or a bug?  Am I likely doing something wrong?

The dismax parser doesn't pay any attention to the default query 
operator.  in the absence of these values in the actual query, edismax 
likely doesn't either.  What matters is the value of the mm variable, 
also known as "minimum 'should' match."  If your mm value is 50%, which 
is a common value to see in dismax examples, I believe it would behave 
exactly like you are seeing.

This is a complex little beast.  Just a couple of weeks ago, Chris 
Hostetter said that although he wrote the code and the syntax for mm, 
the explanation for the parameter that's in the Smiley and Pugh Solr 
book (pages 138-140) is the clearest he's ever seen.

Here's some detailed documentation on it.  I can't find my copy of the 
book right now, so I don't know if this is as good as what's in it:

http://lucene.apache.org/solr/api/org/apache/solr/util/doc-files/min-should-match.html

Hopefully this is applicable to you, and not something you already 
thought of!

Shawn

Reply via email to