: You are right, SimpleFacets#getFacetQueryCounts has the following comment:
:
: /* Ignore SolrParams.DF - could have init param facet.query assuming
: * the schema default with query param DF intented to only affect Q.
: * If user doesn't want schema default for facet.query, they should be
: * explicit.
: */
that comment is a red-herring...
1) "DF" is the "df" param which changes the defaultField
2) that comment refers to a line of code that is commented out because it
predates the Qparser stuff
However, Stephen's comments that changing defType didn't affect
facet.query jogged my memory about something...
https://issues.apache.org/jira/browse/SOLR-1025
...based on yonik's comments there, it sems intentional that defType isn't
"inherited" by more parsers the the main one (either in other top level
params, or in nested parsers)
The sub parsers trick could be useful here, hardcode...
facet.query={!custom v=$custom.facet.query}
...as an invariant in solrconfig and then have your users pass the
"custom.facet.query" param instead of "facet.query" ... btu that won't
work for multivalued params.
For facet.query we could add a new param to the FacetComponent to
default/invariant the parser, in the more general case of all params that
might want parsing perhaps we could think of a new option that would let
people declare a prefix on all params of a given name -- or a new option
on the sub-parser syntax that would force the main param to be cloned for
each instance of the sub param, so that something like...
a={!foo s=t v=$$x}&x=1&x=2&b={!bar v=$y}y=8&y=9
...would be equivilent to...
a={!foo s=t}1&a={!foo s=t}2&b={!bar}8
(note the "$$" in a and the "$" in b)
...something like that would be pretty cool, but a pain in the ass to
implement (because right now the pultiparam code is completely isolated
from the query parser code) ... it's pie in the sky, but maybel it will
help people think of simpler/better alternatives.
-Hoss
