lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Date Facet duplicate counts
Date Sun, 17 Jan 2010 03:23:30 GMT

: For reference, a related thread topic can be found here: 
: Was this done for a reason - are there any implications somewhere else 

A major reason was mentioned in my econd reply to the thread you 

...we wanted to make sure the counts accurately represented what you would 
get if you then filtered on that date range -- and since the query parser 
only supported ranges that were inclusive on both ends we wound up with 
this. some improvements to the QUeryparser to support mixed use of [] and 
{} (ie: "date:[A TO B}") would help, but that leads to another small 

should we be inclusive of the lower or the upper? ... even if we make it 
an option, how should it apply to the "first" and "last" ranges computed?  
do the answers change if includes "before" and/or "after"  
should the "between" option be inclusive of both end points as well?

...lots of little nuances subtleties that ultimately lead to the decisiosn 
that for the time being it was simple, easy, and straight forward to just 
always be inclusive, and add support for more complexities later.

In practice: people either don't notice, don't care, or find it easy 
enough to add/subtract 1 millisecond to their times to get the behavior 
they want.

: If interested parties are in agreement, I can create an issue for it and the associated

If you can suggest some semantics for a new option to control the 
inclusion/exclusion of the endpoints on all of the various edge cases, 
that is straight forward and easy to understand, that would certainly be a 
nice addition.  we can worry about the query parser aspect of filtering on 
those ranges later and people who want to use the new option at the 
expensive of being able to have consistent counts when filtering can turn 
it on.


View raw message