My plan has been to use unix timestamps as integer fields. I also was ooing to use 'all balls' time for dates without time. Midnight is actually AM, so I was going to count it as the next day.
To get my range, I was going to use a greater than, and then a less than for the two intgeres, calculating them outside of Solr/Lucene and putting them into the query. Anybody have any thoughts to how fast that would be compared to the range query for dates? Dennis Gearon Signature Warning ---------------- EARTH has a Right To Life, otherwise we all die. Read 'Hot, Flat, and Crowded' Laugh at http://www.yert.com/film.php --- On Thu, 9/9/10, Liam O'Boyle <liam.obo...@intelligencebank.com> wrote: > From: Liam O'Boyle <liam.obo...@intelligencebank.com> > Subject: Re: Date faceting +1MONTH problem > To: solr-user@lucene.apache.org > Date: Thursday, September 9, 2010, 4:20 PM > 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! > > > > >
