Hmm, that makes sense to me - however I still think that even if we
have mm set to "2" and we have "the 7449078" it should still match
7449078 in a productId field (it does not: http://zeta.zappos.com/search?department=&term=the+7449078)
. This seems like it works against the way one would reasonably expect
it to - that stopwords shouldn't impact the counts for mm (so, "the
7449078" would count as 1 term for mm since "the" is a stopword).
Would there be a way around this? Could we possibly get it reworked?
What would the downside to that be?
We have people asking for "the north" to return results from a brand
called "the north face" - but it doesn't, and can't, because of this
mm issue.
Thanks for your time helping us with this issue =)
Matthew Runo
Software Engineer, Zappos.com
mr...@zappos.com - 702-943-7833
On Dec 20, 2008, at 10:45 AM, Chris Hostetter wrote:
: 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)?
not really ... that's kind of a special usecase. if someone
searches for
a productId that's usually *all* they search for (1 "chunk" of input
fro
mthe query parser) so it's mandatory and produces a clause across all
fields. It doesn't matter if the other fields have stopwords --
even if
the productId happens to be a stop word, that just means it doesn't
produce a clause on those "stop worded" fields, but it will will on
your
productId field.
The only case where you might get into trouble is if someone
searches for
"the 123456" ... now you have two chunks of input, so the mm param
comes into play you have no stopwords on your productId field so both
"the" and "123456" produce clauses, but "the" isn't going to be
found in
your productId field, and because of stopwords it doens't exist in the
other fields at all ... so you don't match anything.
FWIW: if i remember right if you want to put numeric fields in the
qf, i
think you need *all* of them to be numeric and all of your input
needs to
be numeric, or you get exceptions from the FieldType (not the dismax
parser) when people search for normal words. i always copyField
productId into a productId_str field for purposes like this.
-Hoss
