OK, here's a prototype (still needs string-constants, distrib support, and tests) that implements support for multi-select facets by allowing the tagging of any query via the existing "localParams" syntax. It adds localParams support to facet commands like facet.field to allow exclusion of certain filters.

fq=

type:pdf&facet.field=

myfield

both tag and ex may be a comma separated list to allow storing under different tags and selecting multiple tags.

The localParams method seems preferable since it can be arbitrarily extended for other controls, and already existed when parsing queries.

This patch also adds the ability to specify a different output name/key... useful for complex facet queries:

facet.query=

rng:[1 TO 2] OR rng:[5 TO 9]
will cause the results to come back under a key of "foo" rather than "rng:[1 TO 2] OR rng:[5 TO 9]"

facet.query={!key=foo}rng:[1 TO 2] OR rng:[5 TO 9]

nice!

Another goodie to overload into the local params is something maybe like

to prevent filling up the filter cache with something that is not meant to be reused or often. There's another implementation over at SOLR-407.

Whew, things got complicated in distributed search.... refinement queries need to keep the same exclusions so that they get the right count. I decided to implement a different approach that specifies a comma separated list of terms for the facet.field when refining. This should result in much smaller refinement requests, less parsing overhead, and smaller response sizes.

Attaching latest draft... only thing left is to make some string constants I think.

Attaching finished patch.
I'll wait a little while before committing to give time for others to review the API and suggest changes.

This patch also adds the ability to specify a different output name/key... useful for complex facet queries:

facet.query={!key=foo}rng:[1 TO 2] OR rng:[5 TO 9]
will cause the results to come back under a key of "foo" rather than "rng:[1 TO 2] OR rng:[5 TO 9]"

but then how will the client know how what to filter on to actually constrain the query by "foo" since it won't actually ko what query that was?

but then how will the client know how what to filter on to actually constrain the query by "foo" since it won't actually ko what query that was?

Well, it's optional... it's only an issue for stateless clients without conventions or application specific knowledge - and they could always look at the original parameters via echoParams.

Well, it's optional... it's only an issue for stateless clients without conventions or application specific knowledge - and they could always look at the original parameters via echoParams.

that assumes it wasn't baked into the config file.

I guess there's no harm in adding it (except perhaps confusion: i'd hate to see people assume that they can add "fq=key" since they got "key" back in the facet_queries section of the response)

my point was really just that facet constraint "labels" are really only useful if each label is easily associated with a way of applying that constraint. replacing the query string with a "key" in the response is only useful if that key can be used for something.

It seems to me like it would be far more useful to just reserve "key" as a special local param that we guarantee will never get used, so people can include it in the facet.query and then parse it out of the response themselves.

You can already do this today...

In Config...
    <lst name="defaults">
      <str name="facet.query">{!ignoredparam="Low Price"}price:[* TO 500]</str>
      <str name="facet.query">{!ignoredparam="Hight Price"}price:[500 TO *]</str>
      ...
In Query Response...
   <lst name="facet_queries">
     <int name="{!ignoredparam="Low Price"}price:[* TO 500]">3</int>
     <int name="{!ignoredparam="Hight Price"}price:[500 TO *]">0</int>
     ...

...but it would be nice to have a parma name reserved for this.

(admittedly it never occurred to me until this Jira post that that worked, i'm going to start encouraging every one i know to start doing that)

Committed. I don't believe there are changes suggested to the API, just possible additions.
We can iterate or improve before 1.4.

Bulk close for Solr 1.4