lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter 4U <>
Subject RE: Reverse sort facet query [SOLR-1672]
Date Mon, 04 Jan 2010 15:07:02 GMT


> Date: Sun, 3 Jan 2010 22:18:33 -0800
> From:
> To:
> Subject: RE: Reverse sort facet query [SOLR-1672]
> : Yes, I thought about adding some 'new syntax', but I opted for a separate 'facet.sortorder'
> : 
> : 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
it this way.
> it shouldn't really affect anything -- it wouldn't really be new syntax, 
> just extending hte existing "sort" param syntax to apply to the 
> "facet.sort" param. The only back compat concern is making sure we 
> continue to support true/false as aliases, and having the default order 
> match the current bahvior if asc/desc aren't specified.
> -Hoss

Yes, agreed. The current patch doesn't touch the b/w true/false aliasing, and any move to
adding a new attr can keep all that intact.

I've been using the current patch extensively in our testing, and that's 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 results start with
the first count=1. This could be confusing as

there could well be many facets whose count is 0, and it might be expected that these be returned
in the first instance.

>From my admittedly cursory look into the codebase regading this, I 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 SimpleFacets/UnInvertedField would affect performance
and compatibility.

If there is indeed a performance optimization in facet counting iteration, it would, imo,
be preferable to have the optimization, rather than the 0-counts.


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";


I can then easily modify the patch to detect/use this value to invoke the new behaviour.

Comments? Suggestions?







Have more than one Hotmail account? Link them together to easily access both
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message