: But if lucene now can sort a multi-valued field without crashing when there : are 'too many' unique values, and with easily described and predictable : semantics (use the minimal value in the multi-valued field as sort key) -- : then it probably makes more sense for Solr to let you do that if you really : want to, give you enough rope to hang yourself.
(Clarification: it's the the *maximal* value that gets used by lucene in that situation) I disagree. If we do what you describe we'd be relying on users to recognize when the sort logic is silently doing something "tricky" under the covers and make a concious decision as to if that was what they want, and if not then change their indexing to account for it. That seems like a recipe for confusion and unexpected behavior. with SOLR-2339 in place, we tell users explicitly and up front "what you are attempting to do can not work as specified" and we force them to decide in advance how they want to deal with it -- by either indexing the lowest value or hte highest value (or both in distinct fields). As the code stands now: we fail fast and let the person building hte index make a decision. If we silently sort on the maximal value, we leave nasty headache for people who don't realize they are missusing a multiValued field and then wonder why some sorts don't do what they expect in some situations. Bottom line: from day 1, we have always documented that sorting on multiValued fields (or fields that produced more then one document per document) didn't work. If people didn't notice that documentation, they aren't likely to notice any documentation that says it will sort on the maximal value either -- SOLR-2339 may introduce a pain point for people upgrading, but it introduces it early and loudly, not quietly at some arbitrary moment in the future when they're beating their heads against a desk wondering why some sort isn't working the way they expect it to becuase they added some more values to a few documents. -Hoss
