[
https://issues.apache.org/jira/browse/SOLR-12839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16649387#comment-16649387
]
Yonik Seeley commented on SOLR-12839:
-------------------------------------
bq. if "foo desc" is the primary sort, and "bar asc" is the tiebreaker, then
what is being resorted on?
"foo desc, bar asc 50" was an example of a single sort with tiebreak and a
limit (no resort).
If one wanted a single string version ";" would be the divider. For example
adding a resort with a tiebreak: "foo desc, bar asc 50; baz desc, qux asc 10"
bq. why/how/when would it make sense to resort multiple times?
If there are use cases for starting with N sorted things and reducing that to K
with a different sort, then it's just sort of recursive. Why would there be
use cases for one resort and not two resorts?
One use case that comes to mind are stock screens I've seen that consist of
multiple sorting and "take top N" steps.
Example: Sort by current dividend yield and take the top 100, then sort those
by low PE and take the top 50, then sort those by total return 1 year and take
the top 10.
bq. or how it could work practically given the 2 phrase nature of distributed
facet refinement.
Hmm, good point. Over the long term I'd always imagined the number of phases
could be variable, so It's more of a current implementation detail (albeit a
very major one). It would currently kill the usefulness in distributed though.
Anyway we don't have to worry about multiple resorts now as long as we can
unambiguously upgrade if desired later (i.e. whatever the resort spec looks
like, if we can unambiguously wrap an array around it later and specify
multiple of them, then we're good)
> add a 'resort' option to JSON faceting
> --------------------------------------
>
> Key: SOLR-12839
> URL: https://issues.apache.org/jira/browse/SOLR-12839
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Major
> Attachments: SOLR-12839.patch, SOLR-12839.patch
>
>
> As discusssed in SOLR-9480 ...
> bq. Similar to how the {{rerank}} request param allows people to collect &
> score documents using a "cheap" query, and then re-score the top N using a
> ore expensive query, I think it would be handy if JSON Facets supported a
> {{resort}} option that could be used on any FacetRequestSorted instance right
> along side the {{sort}} param, using the same JSON syntax, so that clients
> could have Solr internaly sort all the facet buckets by something simple
> (like count) and then "Re-Sort" the top N=limit (or maybe (
> N=limit+overrequest ?) using a more expensive function like skg()
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
