On 13.08.2011 21:28 Erick Erickson wrote: > Fair enough, but what's "first value in the list"? > There's nothing special about "mutliValued" fields, > that is where the schema has "multiValued=true". > under the covers, this is no different than just > concatenating all the values together and putting them > in at one go, except for some games with the > position between one term and another > (positionIncrementGap). Part of my confusion is > that the term multi-valued is sometimes used to > refer to "multiValued=true" and sometimes used > to refer to documents with more than one > *token* in a particular field (often as the result > of the analysis chain)
I guess, since multivalued fields are not really different under the hood, they should be treated the same. So, no matter if the different values are the result of a "multiValued=true" or of the analysis chain: if the whole thing starts with an "a" put it first, if it starts with a "z" put it last. Example (multivalued field): Smith, Adam Duck, Dagobert => sort as "s" (or "S") Example tokenized field: This is a tokenized field => sort as "t" (or "T") > The second case seems to be more in the > grouping/field collapsing arena, although > that doesn't work on fields with more than one > value yet either. But that seems a more sensible > place to put the second case rather than > overloading sorting. It depends how you see the meaning of sorting: 1. Sort the records based on one single value per record (and return them in this order) 2. Sort the values of the field to sort on (and return the records belonging to the respective values) As long as sorting is only allowed on single value fields, both are identical. As soon as you allow multivalued fields to be sorted on, both interpretations mean something different and I think both have their valid use case. But I don't want to stress this too far. -Michael
