: But it would be a lot harder than either splitting them out into : separate docs, or writing code to re-index docs when one of their : 'next-event' dates passes, with a new single valued 'next-event' field. : Less efficient, but easier to write/manage.
Don't get me wrong -- if you can determine at index time which single value you wnat to use to sort on then by all means that is going to be the best approach -- it's precisely the reason why FirstFieldValueUpdateProcessorFactory, LastFieldValueUpdateProcessorFactory, MaxFieldValueUpdateProcessorFactory, and MinFieldValueUpdateProcessorFactory. But my interpretation of "the next" start time is that it wsa dependent on the value of "NOW" when the query was executed (ie: some of the indexed values may be in the past) in which case that approach wouldn't work. : On Tue, Dec 4, 2012, at 07:35 PM, Chris Hostetter wrote: : > : > : perfectly, but users expect the result set to be ordered by the next : > start : > : time. : > ... : > : Is there a more elegant way to do this in Solr? A function query or : > : subquery maybe? I thought about it for quite a while and couldn't come : > up : > : with a viable solution. : > : > I think you could concievably write a custom function that built an : > UnInvertedField over your multivalued field, and then returned the : > "lowest : > value for each doc where the value is after 'NOW'" but there is nothing : > out of the box that will do this for you (and i haven't really thought : > hard about how viable this approach is ... i can't think of any obvious : > problems off the top of my head) : > : > -Hoss : -Hoss
