: i.e. just extend facet.sort to allow a 'count desc'. By convention, ok
: to use a a space in the name? - or would count.desc (and count.asc as
: alias for count) be more compliant?
i would use space to remain consistent with the existing "sort"
param.
it might even make sense to refactor (
>
> now i'm totally confused: what are you suggesting this new param would
> do, what does the name mean?
>
Sorry, I wan't clear - there isn't a new parameter, except the one added in the
patch. What I was suggesting here is to do the work
to remove the new parameter I just put in (facet.sorto
: 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
> Date: Sun, 3 Jan 2010 22:18:33 -0800
> From: hossman_luc...@fucit.org
> To: solr-user@lucene.apache.org
> Subject: RE: Reverse sort facet query [SOLR-1672]
>
>
> : Yes, I thought about adding some 'new syntax', but I opted for a separate
> 'face
: Yes, I thought about adding some 'new syntax', but I opted for a separate
'facet.sortorder' parameter,
:
: mainly because I'm not familiar enough with the codebase to know what effect
this might have on
:
: backward compatibility. It would be easy enough to modify the patch I created
to do
> in Solr 1.4 the boolean syntax was deprecated in place of keywords that
> are more meaninful...
> http://wiki.apache.org/solr/SimpleFacetParameters#facet.sort
>
> ... "count" and "index" replaced "true" and "false"
Yes, I thought about adding some 'new syntax', but I opted for a separate
'f
