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
