> 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 
> '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 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?

 

Thanks,

Peter

 

 

 

 
                                          
_________________________________________________________________
Have more than one Hotmail account? Link them together to easily access both
 http://clk.atdmt.com/UKM/go/186394591/direct/01/

Reply via email to