[
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644279#comment-13644279
]
Shai Erera commented on LUCENE-4965:
------------------------------------
bq. Ie overlapping ranges should be allowed?
Ahh, you're right.
bq. it's a little tricky to do that since each Range has its own private min/max
Maybe Range can implement Comparable, and you build the tree using it, like we
build PQ? In practice though, I wonder how much more efficient a tree would be
vs simply sorting and iterating until a range is bigger than value? We're
talking probably very few ranges no?
BTW, I think Range would need to implement Comparable as well as
compareTo(long) since a value may not fall into the first (sorted order) range
(e.g. range.accept() returns false), but you'll need to continue looking until
range.compareTo(long) > 0 (i.e. range.minValue > value).
Also, maybe instead of FRN we should return a RangeFRN which contains the
range? That way, someone can extract the min/max values of the range without
parsing the label by casting to the range added? Hmm, but then you'll need to
make the range impls public, but maybe that's not bad? Instead of
Range.newLongRange, someone will just do {{new LongRange()}}?
I see you decided not to go with generics? In that case, maybe document that
you are expected to pass the same Range type? Although, why not make
RangeFacetRequest generic and prevent this pitfall?
> Add dynamic numeric range faceting
> ----------------------------------
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch,
> LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc. But because time is constantly advancing,
> doing this at index time is a not easy ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
