By the way, this could be done automatically by Solr or Lucene behind the scenes.
Bill Bell Sent from mobile On Mar 17, 2011, at 9:02 AM, Bill Bell <billnb...@gmail.com> wrote: > Here is a work around. Stick the high value and low value into other fields. > Use those fields for sorting. > > Bill Bell > Sent from mobile > > > On Mar 17, 2011, at 8:49 AM, Yonik Seeley <yo...@lucidimagination.com> wrote: > >> On Wed, Mar 16, 2011 at 6:08 PM, Jonathan Rochkind <rochk...@jhu.edu> wrote: >>> Also... if lucene is already capable of sorting on multi-valued field by >>> choosing the largest value.... largest vs. smallest is presumably just >>> arbitrary there, there is presumably no performance implication to choosing >>> the smallest instead of the largest. It just chooses the largest, according >>> to Yonik. >> >> It's a little more complicated than that. >> It's not so much an explicit feature in lucene, but just what >> naturally happens when building the field cache via uninverting an >> indexed field. >> >> It's pretty much this: >> >> for every term in the field: >> for every document that matches that term: >> value[document] = term >> >> And since terms are iterated from smallest to largest (and no, you >> can't reverse this) >> larger values end up overwriting smaller values. >> There's no simple patch to pick the smallest rather than the largest. >> >> In the past, lucene used to try and detect this multi-valued case by >> checking the number of values set in the whole array. This was >> unreliable though and the check was discarded. >> >> -Yonik >> http://lucidimagination.com
