lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1240) Numerical Range faceting
Date Mon, 26 Jul 2010 19:38:19 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892428#action_12892428
] 

Hoss Man commented on SOLR-1240:
--------------------------------

bq. Ahh ok, that makes sense. However with the mincount parameter you do not always have the
start parameter, nor do you always have both values of a single count. This not be much of
an issue with dates and integers as you can simply add the gap to the start value but with
floating point numbers I'm a little more wary adding the gap to floating point values due
to rounding errors.

Whoa .. you just blew my mind.

Seriously, i'm not sure how that was so horribly overlooked when mincount support was added
to date faceting -- thank you for bringing this up.

The possibility of rounding errors for an arbitrary range doesn't concern me too much, but
i can see how in some cases it might be a factor if the client code uses differnet floating
point precision then Java does -- like i said, i think something like SOLR-1896 is hte best
way to solve all of that stuff.  What does concern me is your point about how the "first"
range might not be there at all because of the mincount -- that makes it impossible to do
anything useful with the "before" and "between" counts (regardless of any floating point rounding
errors) unless you have echoParams or some other way to "know" what the start value was --
but by that logic you don't need to know what the "gap" is either -- people shouldn't be required
to know what exactly all the query params were to make sense of the data.

we should definitely add the "start" value.

bq. It's just that I'd like it if there were more of a link between the facets one selects
and the filters based on those facets. But I guess that's another discussion.

Agreed ... i'd definitely like to see SOLR-1896 make it trivial to just refer to the "low"
value of any range that comes back from range faceting in an "fq and have solr automaticly
build a range filter with the appropriate upper bound and inclusion properties.

> Numerical Range faceting
> ------------------------
>
>                 Key: SOLR-1240
>                 URL: https://issues.apache.org/jira/browse/SOLR-1240
>             Project: Solr
>          Issue Type: New Feature
>          Components: search
>            Reporter: Gijs Kunze
>            Priority: Minor
>         Attachments: SOLR-1240.patch, SOLR-1240.patch, SOLR-1240.patch, SOLR-1240.patch,
SOLR-1240.patch, SOLR-1240.patch, SOLR-1240.patch, SOLR-1240.patch
>
>
> For faceting numerical ranges using many facet.query query arguments leads to unmanageably
large queries as the fields you facet over increase. Adding the same faceting parameter for
numbers which already exists for dates should fix this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message