: working well. The only caveat to this is that the reverse sort results
: don't include 0-count facets (see notes in SOLR-1672), so reverse sort
...
: believe patching to include 0 counts could open a can of worms in terms
: of b/w compat and performance, as 0 counts look to be skipped (by
: default). I could be wrong, and you may know better how changes to
Hmmm... that behavior should all be driven by facet.mincount. i haven't
look at that code in a long time, so an optimization may have been added
to not bother trying to "sort" all of the 0s ... but the default for
facet.mincount is 0 (ie: show everything)
: Would you like me to go ahead and amend the patch (w/o 0-counts) to define a
new 'sort' parameter?
:
: For naming, I would propose an extension of FacetParams.FACET_SORT_COUNT ala:
:
: public static final String FACET_SORT_COUNT_REVERSE = "count.reverse";
now i'm totally confused: what are you suggesting this new param would
do, what does the name mean?
my original point was that we probably don't need any new params at all:
just change facet.sort to accept "count desc" and "count asc" in addition
to "count" (which would become an alias for "count desc").
-Hoss
