Chris Hostetter wrote:
: When I added numerical faceting to my checkout of solr (solr-1240) I basically
: copied date faceting and modified it to work with numbers instead of dates.
: With numbers I got a lot of doulbe-counted values as well. So to fix my
: problem I added an extra parameter to number faceting where you can specify if
: either end of each range should be inclusive or exclusive. I just ported it
gwk:
1) would you mind opening a Jira issue for your date faceting improvements
as well (email attachments tend to get lost, and there are legal headaches
with committing them that Jira solves by asking you explicitly if you
license them to the ASF)
Sure, I've added it to Jira https://issues.apache.org/jira/browse/SOLR-1402.
2) i haven't looked t your patch, but one of the reasons i never
implemented an option like this with date faceting is that the query
parser doesn't have any way of letting you write a query that is inclusive
on one end, and exclusive on the other end -- so you might get accurate
facet counts for range A-B and B-C (inclusive of the lower, exclusive of
hte upp), but if you try to filter by one of those ranges, your counts
will be off. did you find a nice solution for this?
I ran into that problem as well but the solution was provided to me by
this very list :) See
http://www.nabble.com/Range-queries-td24057317.html It's not the
cleanest solution, but as long as you know what you're doing it's not
that bad.
The reason I created 1240 was exactly because my counts were off, with
date faceting exact matches are a rarity, or at least you can make them
to be one. But since with numbers (in my case, prices) being off by 1
cent is not acceptable I needed this exclusivity. The only real reason
for all of this was the geek-candy the price slider on our website, the
counts are sent via ajax and the range slider can simply sum the counts
for the selected range to get the exact count for that range without
having to query Solr for more data.
Regards,
gwk
