Just attended a talk at JavaZone (www.javazone.no) by Stephen Colebourne about JSR-310 which will make these kind of operations easier in future JDK, and how Joda-Time goes a great way of enabling it today. I'm not saying it would fix your GAP issue, as it's all about what definition of "month" we want to have in Solr, which may also vary between usecases. For faceting it makes perfect sense to follow calendar months.
Wouldn't this behaviour occur between 31 and 30 days months as well, e.g. 2009-08-31 -> 2009-09-30 -> 2009-10-30 ? For your particular usecase I would consider a workaround where you add a new year-month field for this kind of faceting, avoiding date math completely since it will be a string facet, giving you: [2008-12] => 0 [2009-01] => 0 [2009-02] => 0 [2009-03] => 0 [2009-04] => 0 -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com On 10. sep. 2010, at 01.20, Liam O'Boyle wrote: > Hi Chris, > > Yes, I saw the facet.range.include feature and briefly tried to implement it > before realising that it was Solr 3.1 only :) I agree that it seems like > the best solution to problem. > > Reindexing with a +1MILLI hack had occurred to me and I guess that's what > I'll do in the meantime; it just seemed like something that people must have > run into before! I suppose it depends on the granularity of your > timestamps; all of my values are actually just dates, so I've been putting > them in as the date with T00:00:00.000Z, which makes the overlap problem > very obvious. > > If anyone else has come across a solution for this, feel free to suggest > another approach, otherwise it's reindexing time. > > Cheers, > Liam > > > On Fri, Sep 10, 2010 at 8:38 AM, Chris Hostetter > <hossman_luc...@fucit.org>wrote: > >> : I'm trying to break down the data over a year into facets by month; to >> avoid >> : overlap, I'm using -1MILLI on the start and end dates and using a gap of >> : +1MONTH. >> : >> : However, it seems like February completely breaks my monthly cycles, >> leading >> >> Yep. >> >> Everything you posted makes sense to me in how DateMath works - "Jan 31 @ >> 23:59.999" + "1 MONTH" results in "Feb 28 @ 23:59.999" ... at which point >> adding "1 MONTH" to that results in "Mar 28 @ ..." because there is no >> context of what the initial starting point was. >> >> It's not a situation i've ever personally run into ... one workarround >> would be to use a "+1MILLI" fudge factor at indexing time, instead of a >> "-1MILLI" fudge factor at query time ... that shouldn't have this problem. >> >> If you'd like to open a bug to trak this, I think it might be possible to >> fix this behavior (there are some features in the Java calendaring code >> that make things like "Jan 31 + 2 Months" do the right thing) but >> personally I think working on SOLR-1896 (combined with the new >> facet.range.include param) is a more effective use of time so >> we can eliminate the need for this type of hack completely in future Solr >> releases. >> >> -Hoss >> >> -- >> http://lucenerevolution.org/ ... October 7-8, Boston >> http://bit.ly/stump-hoss ... Stump The Chump! >> >>
