: 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