[jira] [Commented] (LUCENE-4965) Add dynamic numeric range faceting

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (LUCENE-4965) Add dynamic numeric range faceting

Sebastian Nagel (Jira)

    [ 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: [hidden email]
For additional commands, e-mail: [hidden email]