Would this mean that, for example, if we wanted to search productId
(long) we'd need to make a field type that had stopwords in it rather
than simply using (long)?
Thanks for your time!
Matthew Runo
Software Engineer, Zappos.com
mr...@zappos.com - 702-943-7833
On Dec 12, 2008, at 11:56 PM, Chris Hostetter wrote:
: I have discovered some weirdness with our Minimum Match
functionality.
: Essentially it comes up with absolutely no results on certain
queries.
: Basically, searches with 2 words and 1 being ³the² don¹t have a
return
: result. From what we can gather the minimum match criteria is
making it
: such that if there are 2 words then both are required.
Unfortunately, the
you haven't mentioned what qf you're using, and you only listed one
field
type, which includes stopwords -- but i suspect your qf contains at
least
one field that *doesn't* remove stopwords.
this is in fact an unfortunate aspect of the way dismax works --
each "chunk" of text recognized by the querypaser is passed to each
analyzer for each field. Any chunk that produces a query for a field
becomes a DisjunctionMaxQuery, and is included in the "mm" count --
even
if that "chunk" is a stopword in every other field (and produces no
query)
so you have to either be consistent with your stopwords across all
fields,
or make your mm really small. searching for "dismax stopwords"
turns this
up...
http://www.nabble.com/Re%3A-DisMax-request-handler-doesn%27t-work-with-stopwords--p11016770.html
...if i'm wrong about your situation (some fields in the qf with
stopwords
and some fields without) then please post all of the params you are
using
(not just mm) and the full parsedquery_tostring from when
debugQuery=true
is turned on.
-Hoss
