> Chris Hostetter wrote: > > You can see that in the resulting URL you got the params are duplicated -- the > problem is that when expressed this way, Solr doesn't know when the > different values of the start/end/gap params should be applied -- it just > loops over each of the facet.range fields (in your case: the same field > twice) and then looks for a coorisponding start/end/gap value and finds the > first one since there are duplicates.
OK, that explains it. I thought that it would match the params, so that it would match the first parameter "facet.range=scheduledate_start_tdate" with the first parameter "f.scheduledate_start_tdate.facet.range.start=1990-01-01T11:00:00.000Z", the second parameter "facet.range=scheduledate_start_tdate" with the second parameter "f.scheduledate_start_tdate.facet.range.start=2011-01-01T11:00:00.000Z" and so on. > what you want to do can be accomplished (as of Solr 4.3 - see SOLR-1351) by > using "local params" in the facet.range (or facet.date) params... > > http://localhost:8983/solr/select?q=*:*&rows=0&facet=true&facet.range={! > facet.range.start=NOW/MONTH%20facet.range.end=NOW/MONTH%2B1M > ONTH%20facet.range.gap=%2B1DAY}manufacturedate_dt&facet.range={!fa > cet.range.start=NOW/MONTH%20facet.range.end=NOW/MONTH%2B1MO > NTH%20facet.range.gap=%2B5DAY}manufacturedate_dt Thanks for this info. I'm not sure it is easy to upgrade Solr for us though, since it is more or less integrated into the CMS we use. But I actually realized that for this particular case, we don't need different gap sizes. We can use the "before" and "after" metadata instead. Regards /Jimi
