[
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643912#comment-13643912
]
Shai Erera commented on LUCENE-4965:
------------------------------------
Looks great! Few comments:
* I think the Accumulator should not take FSP, just the ndv field, for various
reasons:
** It will eliminate the need for the checks about the validity of FSP
** When I read the test, it seemed awkward to me that you need to create a FSP
and CountingFR, since 'field' is not a facet at all...
* If you change FacetsAccumulator to not initialize a FacetArrays, you can
safely pass null for taxonomy and FacetArrays
* I think the only reason you override getAggregator is because
FacetsCollector.create() calls it to determine if doc scores are needed?
** Maybe we can have FacetsAccumulator.requiresDocScore() -- the default will
call getAggregator().requireDocScore() and you will just return false? Then FC
will use the accumulator to determine that.
* Regarding the "nocommit int/float/double too", I think this class should be
called DynamicLongRangeAccumulator since it can only handle longs. To handle
int/float/double, you will need to override accumulate() entirely to pull a
different DV and find the range.
** If you make this class abstract, you can have a utility method which
converts the ranges to FacetResultNodes.
* {{if (r.count > 0)}} -- I think that's wrong? We should return all requested
ranges, some may be with count=0. Just like we return in normal faceted search
a FacetResult per FacetRequest.
* Instead of addLongRange, can the ctor take an {{IndexReader}} and
{{LongRange...}}? The ranges need to be final (there's no sense adding a new
range after accumulate), and also, I think that the start/endInclusive logic
may not be that simple when you come to handle a FloatRange.
> 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
>
>
> 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
