facet.sort parameter
Hi all, I've been thinking about redesigning the facet.sort parameter (mostly because of the issues arising from SOLR-764). I'll briefly outline my concerns. - facet.sort=false and facet.sort=true don't do what one would intuitively think they do -- both return the facets sorted, just how they're sorted is different - sorting by term order is probably only used because it also happens to sort lexicographically -- the Luncene-internal term number shouldn't be used for anything by application programmers IMHO - facet.sort=false, i.e. sort by term order, is meaningless in a distributed setup as there are no distributed term numbers The redesign I propose is changing the facet.sort parameter from a boolean to a string and explicitely specify the sort method (with a default method if the parameter isn't specified). You'd use facet.sort=count to sort by facet count and something like facet.sort=lex to sort lexicographically. This would be using term order internally, but not expose it. This redesign would also increase the flexibility as more sort methods can be added easily. What does everybody think? Lars
Re: facet.sort parameter
I'm not a huge facet user, so I can't tell with certainty how good your suggestion is, but from your description the change sounds good. It also reminds me what I did here: http://www.simpy.com/user/otis/links If you look above the tags on the right side of the page you will see: "View: alpha · freq · cloud" eight under "Top Tags". If you look at the URLs for each of those 3 links (alpha, freq, cloud), it more or less matches what I think you are suggesting. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Lars Kotthoff <[EMAIL PROTECTED]> > To: solr-dev@lucene.apache.org > Sent: Friday, September 19, 2008 7:41:55 AM > Subject: facet.sort parameter > > Hi all, > > I've been thinking about redesigning the facet.sort parameter (mostly because > of the issues arising from SOLR-764). I'll briefly outline my concerns. > > - facet.sort=false and facet.sort=true don't do what one would intuitively > think > they do -- both return the facets sorted, just how they're sorted is > different > - sorting by term order is probably only used because it also happens to sort > lexicographically -- the Luncene-internal term number shouldn't be used for > anything by application programmers IMHO > - facet.sort=false, i.e. sort by term order, is meaningless in a distributed > setup as there are no distributed term numbers > > The redesign I propose is changing the facet.sort parameter from a boolean to > a > string and explicitely specify the sort method (with a default method if the > parameter isn't specified). You'd use facet.sort=count to sort by facet count > and something like facet.sort=lex to sort lexicographically. This would be > using > term order internally, but not expose it. This redesign would also increase > the > flexibility as more sort methods can be added easily. > > What does everybody think? > > Lars
Re: facet.sort parameter
Changing the facet.sort parameter to a string will be backwards-incompatible. Do we have any other option? On Fri, Sep 19, 2008 at 5:11 PM, Lars Kotthoff <[EMAIL PROTECTED]> wrote: > Hi all, > > I've been thinking about redesigning the facet.sort parameter (mostly > because > of the issues arising from SOLR-764). I'll briefly outline my concerns. > > - facet.sort=false and facet.sort=true don't do what one would intuitively > think > they do -- both return the facets sorted, just how they're sorted is > different > - sorting by term order is probably only used because it also happens to > sort > lexicographically -- the Luncene-internal term number shouldn't be used > for > anything by application programmers IMHO > - facet.sort=false, i.e. sort by term order, is meaningless in a > distributed > setup as there are no distributed term numbers > > The redesign I propose is changing the facet.sort parameter from a boolean > to a > string and explicitely specify the sort method (with a default method if > the > parameter isn't specified). You'd use facet.sort=count to sort by facet > count > and something like facet.sort=lex to sort lexicographically. This would be > using > term order internally, but not expose it. This redesign would also increase > the > flexibility as more sort methods can be added easily. > > What does everybody think? > > Lars > -- Regards, Shalin Shekhar Mangar.
Re: facet.sort parameter
> Changing the facet.sort parameter to a string will be > backwards-incompatible. Do we have any other option? Well the other option is to keep everything as it is now, which I'm sort of opposed to because of the reasons outlined in my previous email. We could build in some form of backward compatability by parsing the "strings" "true" and "false" and emulate the previous behaviour though. Lars
Re: facet.sort parameter
: The redesign I propose is changing the facet.sort parameter from a boolean to a : string and explicitely specify the sort method (with a default method if the : parameter isn't specified). You'd use facet.sort=count to sort by facet count : and something like facet.sort=lex to sort lexicographically. This would be using : term order internally, but not expose it. This redesign would also increase the : flexibility as more sort methods can be added easily. : : What does everybody think? if i'm understanding you: you're really just suggesting a syntactic change, correct? "true" becomes "count" and "false" becomes "lex" ? I don't really see anything wrong with adding "count" and "lex" as aliases for true/false and deprecating true/false -- i agree that would probably make them easier to remember -- but we need to continue to support true/false for back-compat. (the slightly tricky thing is making it a string param but ensureing stuff continues to work for people who use true to set the params using default configs without getting into ClassCast/instanceOf nightmares) -Hoss
Re: facet.sort parameter
> if i'm understanding you: you're really just suggesting a syntactic > change, correct? "true" becomes "count" and "false" becomes "lex" ? Yes. For now, it would be just that. In the future I guess there'll probably be more ways to sort. > (the slightly tricky thing is making it a string param but ensureing stuff > continues to work for people who use true > to set the params using default configs without getting into > ClassCast/instanceOf nightmares) Ah, I didn't think about that. I guess there's nothing we can really do about that but maybe warn though. I'll give it some thought. Lars
