: However, many of our multiValued fields are single valued for the majority : of documents in our index so we may not have noticed the incorrect sorting : behaviors.
that would make sense ... if you use a multiValued field as if it were single valued, you would never enocunter a problem. if you had *some* multivalued fields your results would be sorted extremely arbitrarily for those docs that did have multiple values, unless you had more distinct values then you had documents -- at which point you would get a hard crash at query time. : Regardless, I understand the reasoning behind the restriction, I'm : interested in getting around it by using a functionQuery to reduce : multiValued fields to a single value. It sounds like this isn't possible, I don't think we have any functions that do that -- functions are composed of valuesources which may be composed of other value sources but ultimatley the data comes from somewhere, and in every case i can think of (except for constant values) that data comes from the FieldCache -- the same FieldCache used for sorting. I don't think there are any value sources that will let you specify a multiValued field, and then pick one of those values based on a rule/function ... even the "PolyFields used for spatial search work by using multiple field names unde the covers (N distinct field names for an N-dimensional space) : is that correct? Ideally I'd like to sort by the maximum value on : descending sorts and the minimum value on ascending sorts. Is there any : movement towards implementing this sort of behavior? this is a fairly classic usecase of just having multiple fields. even if the logic was implemented to support this at query time, it could never be faster then sorting on asingle valued field that you populat with the min/max at indexing time -- the mantra of fast I/R is that if you can precompute it independently of the individual search critera, you should (it's the whole foundation for why the inverted index exists) -Hoss
