Details
-
Type:
New Feature
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: modules/facet
-
Labels:None
-
Lucene Fields:New, Patch Available
Description
Today RangeAccumulator assumes the ranges should be read from a NumericDocValues field. Would be good if we can modify it, or introduce a new ValueSourceAccumulator which allows you to range-facet on any ValueSource, e.g. one that is generated from an expression.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Attachment | LUCENE-5297.patch [ 12611837 ] |
+1, patch looks good!
Handled the nocommits (improved javadocs). All range tests pass and I see no reason to exercise the API by passing other ValueSources, as the NDV ones are simulated through LongFieldSource. I think it's ready!
| Attachment | LUCENE-5297.patch [ 12611932 ] |
Commit 1538863 from Shai Erera in branch 'dev/trunk'
[ https://svn.apache.org/r1538863 ]
LUCENE-5297: allow range faceting on any ValueSource
Commit 1538864 from Shai Erera in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1538864 ]
LUCENE-5297: allow range faceting on any ValueSource
Committed to trunk and 4x.
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Lucene Fields | New [ 10121 ] | New,Patch Available [ 10121, 10120 ] |
| Assignee | Shai Erera [ shaie ] | |
| Fix Version/s | 4.6 [ 12324999 ] | |
| Fix Version/s | 5.0 [ 12321663 ] | |
| Resolution | Fixed [ 1 ] |
Patch extends RangeFacetRequest to take also a ValueSource and represents the NDV case as LongFieldSource. Also modified RangeAccumulator to use FunctionValues instead of NDV. All TestRangeAccumulator tests pass.
I have nocommits around jdocs, will handle them later. More important is whether this approach is OK, or is it better to separate the accumulator to an NDV one and ValueSource one (I think not, but perhaps others think differently).