Hey Guys, Thanks a lot for your input!
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. If the query was always a NOW query, there would be no problem. I could just re-index the events once a day and re-adjust the value for next start. The problem is that the user has a calendar/datepicker view and can choose a future date within the next year and view events ordered by next-start after that specific day. As I see it now, I have two options: 1) Create a custom function query as suggested by Chris 2) Index seperate documents for every start time and group them by event at query time (3) A third possibility I thought of was to add a field for every day of the year to each document that contains the next-start date for that particular day: next_start_20121212_dt etc. Then I could order by the dynamic field. But as only some of my events are recurring and few of those recurring over long periods of time I think it does not make too much sense. I might go for option two for now as I'm not a big fan of creating (and especially maintaining) custom components. Or is someone with an even better idea out there? ;) Cheers, Thomas On Tue, Dec 4, 2012 at 11:34 PM, Chris Hostetter <hossman_luc...@fucit.org>wrote: > > : 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 >
