I have a different use case. Consider a spatial multivalued field with latlong values for addresses. I would want sort by geodist() to return the closest distance in each group. For example find me the closest restaurant which each doc being a chain name like pizza hut. Or doctors with multiple offices.
Bill Bell Sent from mobile On Aug 13, 2011, at 12:31 PM, Martijn v Groningen <martijn.is.h...@gmail.com> wrote: > The first solution would make sense to me. Some kind of a strategy > mechanism > for this would allow anyone to define their own rules. Duplicating results > would be confusing to me. > > On 13 August 2011 18:39, Michael Lackhoff <mich...@lackhoff.de> wrote: > >> On 13.08.2011 18:03 Erick Erickson wrote: >> >>> The problem I've always had is that I don't quite know what >>> "sorting on multivalued fields" means. If your field had tokens >>> aaaaa and zzzzz, would sorting on that field put the doc >>> at the beginning or end of the list? Sure, you can define >>> rules (first token, last token, average of all tokens (whatever >>> that means)), but each solution would be wrong sometime, >>> somewhere, and/or completely useless. >> >> Of course it would need rules but I think it wouldn't be too hard to >> find rules that are at least far better than the current situation. >> >> My wish would include an option that decides if the field can be used >> just once or every value on its own. If the option is set to FALSE, only >> the first value would be used, if it is TRUE, every value of the field >> would get its place in the result list. >> >> so, if we have e.g. >> record1: ccc and bbb >> record2: aaa and zzz >> it would be either >> record2 (aaa) >> record1 (ccc) >> or >> record2 (aaa) >> record1 (bbb) >> record1 (ccc) >> record2 (zzz) >> >> I find these two outcomes most plausible so I would allow them if >> technical possible but whatever rule looks more plausible to the >> experts: some solution is better than no solution. >> >> -Michael >> > > > > -- > Met vriendelijke groet, > > Martijn van Groningen
