: fq={!field f=category}<insert value, URL encoded of course, here>
There are subtle nuanced cases where "field" won't work properly, which is
why i usually recommend "raw", but there are also subtle nuanced cases
where raw won't work either (although in my opinion those cases are much
less likely in typical faceting)
this is why the "term" parser was added.
I cover this fairly in depth in the notes attached to the relevant slides
here...
http://people.apache.org/~hossman/apachecon2010/facets/
--
raw QParser
* Default Query Parser does special things with whitespace and punctuation
* Problematic when "filtering" on Facet Field Constraints that contain
whitespace or punctuation
* Use the raw parser to filter on an exact Term
fq = {!raw f=category}Books & Magazines
This is utilizing Solr's LocalParams Syntax to embed metadata directly
into the fq param value. {!raw} is the short form of {!type=raw}
You could also alter the default parser, but it's unlikely you would want
all of your query params parsed with the raw parser by default.
One potential pitfall with using the raw QParser is if you facet on
Numeric fields that utilize an encoded representation. (ie: the "TrieFoo"
or "SortableFoo" Field Types. The RawQParser expects truly "Raw" Terms,
but for encoded numeric types the term you get in the facet response is
the "external" value, and RawQParser won't convert that to the internal
value. The field QParser may be a better choice in those situations (it's
the one Yonik recommends) -- However if you have a Query Analyzer that is
not idempotent (a situation that's easy to get in w/o realizing it) it's
very possible to get incorrect results. The term QParser discussed later
will be the best of both worlds.
--
...
--
term QParser
* All of the advantages of the raw QParser
* Will also work on encoded numeric fields
fq = {!term f=category}Books & Magazines fq = {!term f=weight}1.56
SOLR-2113 Tracks this functionality. It has already been committed to the
trunk, so it should certainly be included in Solr 4.0, and it will likely
be back ported and included in Solr 3.1 as well.
--
-Hoss
