: 1. There appears to be (at least) two ways to specify sorting, one : involving an append to the q parm and the other using the sort parm. : Are these exactly equivalent? : : http://localhost/solr/select/?q=martha;author+asc : http://localhost/solr/select/?q=martha&sort=author+asc
They should be, but the first form is heavily deprecated and should not be used : 2. The docs say that sorting can only be applied to non-multivalued : fields. Does this mean that sorting won't work *at all* for : multi-valued fields or only that the behaviour is indeterminate? The behavior is undefined, in that it might return results in an indeterminant order, or it might flat out fail -- it all depends on the nature of the data in the field. Note: it's not specificly that the field must be "non-multivalued" ... even if a field says multiValue="false" it still might not be a valid field to sort on if it uses an Analyzer that produces multiple tokens per field value (so *most* TextField based fields won't work, unless you use the KeywordTOkenizer or something equivilent) : Based on a brief test, sorting a multi-valued field appeared to work : by picking an arbitrary value when multiple values are present and as i recall, that will happen when the number of distinct terms indexed for that field is less then the number of documents in the index ... but if tomorow you add a document that contains a bunch of new terms, and shifts the balance so that there are more terms then documents, any search attempting to sort on that field will start to fail completly. (the specifics of why that happens relate to the underlying Lucene FieldCache specifics ... i won't bother trying to explain it or deven to defend it, because i'm not fond of it at all -- but i haven't thought of any easy ways to improve it that don't suffer performance penalties for the more common case of people sorting on fields that are "ok" to sort on). -Hoss
