lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Updated: (SOLR-1240) Numerical Range faceting
Date Tue, 20 Jul 2010 22:28:51 GMT


Hoss Man updated SOLR-1240:

    Attachment: SOLR-1240.patch

Checkpoint, updated patch...

* Works for all TrieField types (ie: solved the float parse
  problem) by using delegation to a new RangeEndpointCalculator
  abstraction.  we pick the Impl based on the field type, and then use
  it fo all the math and comparisons.  (this is what my previous 
  "StrNumber" idea morphed into once i started working on it .. seemed
  simpler to understand)
* added tests for double/long/int ranges

Note regarding one of my previous comments...

bq. (even if the field type is "long" it's totally reasonable for people to ask for a gap
of "0.5")

this is *not* supported by my updated patch .. the more i started
thinking about it the less it made sense -- it would only be useful to
let people do specify a "float" gap on a "long" field if the field
types would then let you create range queries that would "do the right
thing" when the end points where fractional -- and that's just not the
case.  so for now the "gap" values have to be parsable using the same
type as the field -- but i left flexibility in there so that it
*could* be added later (this was largely in anticipation of directly 
supporting Dates where the "gap" is a DateMath string)

> Numerical Range faceting
> ------------------------
>                 Key: SOLR-1240
>                 URL:
>             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
> 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:
For additional commands, e-mail:

View raw message