[
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644156#comment-13644156
]
Michael McCandless commented on LUCENE-4965:
--------------------------------------------
bq. Range is not really extendable (private ctor) – is that intentional? I
guess there's not much point extending it ...
I suppose if an app had some custom encoding (into the long value in
NumericDVField) then it would need a custom impl? I'll make it protected...
bq. Any reason why not take primitive values and let the user define e.g
Long.MAX_VALUE as an unlimited upper bound?
I was trying to mimic NumericRangeQuery, but I agree: let's just take
primitives.
bq. Accumulate() iterates at the outer loop on matchingDocs, and inner loop on
ranges. I remember while writing FacetsAccumulator that luceneutil was happier
with the other way (matchingDocs inner). Maybe test?
Ahhh right I forgot about that :) I'll just switch it to inner loop on
matchingDocs... I'm not quite set up to perf test this yet :)
bq. Shouldn't if (ranges.ranges.accept(v)) break if there's a match
I think not? Ie overlapping ranges should be allowed? For Jira search I'd
like to have "Past day", "Past 2 days", etc.
bq. While at it, maybe RangeSet should sort the ranges by their minimum value?
Not sure if asymptotically this will matter...
I think we need to use an interval tree here (I put a TODO) ... it's a little
tricky to do that since each Range has its own private min/max ... but I think
we can do this in a followon issue.
> 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
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
