: multi-select in a single request requires getting facets that are
: constrained differently per-facet (and may be constrained differently
: than for the top N docs returned.)
I still feel like we're having a huge disconcet in terminology, and that
there are really two orthoginal issues here.
In all of the GUI lingo i've seen, the concept of "multi-select" can be
related to a single GUI element (in the case of Solr: a single field).
when talking about "multi-select faceting" (even for a single field) there
are two radically differnet use cases:
case#1: when the user selects a constraint, the main result set is
filtered to only documents mathing that constraint and the counts for all
other constraints are reduced accordingly. when the user selects
aditional constraints the main result set and the counts for other
constraints are further refined and limited to the *intersection* of all
selected constraints and the original document set.
case#2: when the user selects a constraint, the main result set is
filtered to only documents mathing that constraint but the counts for all
other constraints remain unaffected. when the user selects
aditional constraints the main result set grows to include the
intersection of the original document set with the *union* of all selected
constraints.
case#1 is currently supported by Solr (for single value fields the use
case is trivial, but Solr also handles the multivalued field use case as
well). case#2 is not currently possible without making two seperate
requests (one with fq's constraining the selected constraints to get the
main results; one w/o those fq's to get the facet counts)
that's what i think of (and what i suspect most people think of) when
discussing multi-value faceting.
: The normal case would be that you only want to remove constraints
: related to what you are faceting on.
: So when faceting on type, disregard any type related filters. When
: faceting on author, disregard any author related filters. If I click
: on "word" docs above, I'd want to see all other constraint counts
: change except for those under 'type".
I *think* i understand what you just said, it sounds like you're
describing the same thing i did in case#2 above but you are adding in
another facet field (author) whose counts should be constrained in the
same way as the main result set when a "type" constraint is selected.
My confusion is that what you just said don't seem to agree with your
suggested syntax...
: Option #3: tag parts of a request using "local params"
: q=foo&fq=date:[1 TO 2]&fq=securityfilter:42&fq={!tag=type}type:(pdf OR
: html)&facet.field=type&facet.field={!exclude=type}author
:
: So here, one fq is tagged with "type" {!tag=type}
: and then excluded when faceting on author.
...if the goal is that filtering on "type" causes the other facet
counts (ie: "author") to be reduced to reflect the new constraint, but you
don't want the type facet counts to change (so that the other type options
don't vanish) then what is the "author" facet field excluding the taged
"fq" ... shouldn't your example be...
q=foo
fq=date:[1 TO 2]
fq=securityfilter:42
fq={!tag=type}type:(pdf OR html)
facet.field={!exclude=type}type
facet.field=author
?
Assuming i'm understand you (and your original example was just
transcriptiong mistake) then i go back to the basic point of my original
question about "huffman encoding the common case ...
should we make "facet.field={!exclude}X" be shorthand for
"facet.field={!exclude=X}X" ?
Alternately: is seems likely that people who want this type of
multi-select behavior will want it for all/most of their facets ... so
perhaps instead of the {!exclude=X} local param, we should add a new
facet.multi=(true|false) param that can be specified on a per-field basis
... so f.type.facet.multi=true means facet.field=type ignores any fq's
where "tag=type". This would probably even be possible as syntactic sugar
in addition to the {!exclude=X} syntax, so in the common case people would
just use facet.multi=true and forget about it, but in weird esoteric
situations where they want filters on field X or field Y to be ignored by
faceting on field Z they could still use "facet.field={!exclude=X,Y}Z"
-Hoss
