[
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644032#comment-13644032
]
Shai Erera commented on LUCENE-4965:
------------------------------------
Thanks Mike. Looks good! Few more comments:
* The nocommit on default aggregator -- I think you can override and throw
Unsupported?
* +1 to move to o.a.l.facet.dynamic, or oal.facet.range.
* DynamicRange:
** thanks for introducing accept(), but I don't think the way it's implemented
can support other impls, such as float/double.
** Perhapd instead DynamicRange should be abstract, with impls for LongRange,
IntRange, FloatRange and DoubleRange, which can then implement accept properly.
*** It won't have min/max, but can keep label.
** Also, that will allow you to add type-safety to DynamicRangeFacetRequest.
I.e. now someone can pass int and float ranges in the same request, which makes
no sense. But if you make it 'typed', one would need to specify the type at
construction, and cannot make mistakes.
*** DRFR would then be defined with {{<T extends DynamicRange>}} and its ctor
would take {{T...}}.
* I think it's ok if the request is called DynamicRange without numerics
because someone can write a DynamicRange impl not on numeric fields. He'll then
need to also write an accumulator though, but as for the request, it's still
about DynamicRange implementations ... in short, I'm +0 if it stays like that
or renamed :).
> 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
>
>
> 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]
