Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
Something i've been thinking about for a while, but SOLR-6562 recently goaded me into opening a jira for...
The ValueSource/FunctionValues API is designed to work with different levels of math precision (int, long, float, double, date, etc...) and the FunctionValues.objectVal() method provides a generic way to fetch an arbitrary type from any FunctionValues instance – which can be in the "preferred" type for a given ValueSource can be retrieved (ie: an "Integer" if the ValueSource corrisponds to the DocValues of an int field).
But for ValueSources thta wrap other value sources (ie: implementing math functions like "sum" or "product" there is no easy way at runtime to know which of the underlying methods on the FunctionValues is the "best" one to call. It would be helpful if FunctionValues or ValueSource had some type of method on it (ie: "canonicalDataType()" that could return some enumeration value inidacting which of the low level various methods (intValue(docid), floatValue(docid), etc...) were best suited for the data it represents.
Straw man idea...
For the lowest level ValueTypes coming from DocValues, these methods could return a constant – but for things like "SumValueSource" "canonicalDataType()" could be recursive – returning the least common denominator of the ValueSources it wraps. the corrisponding intValue() and floatValue() methods in that class could then cast appopriately.
So even if you have SumValueSource wrapped arround several IntDocValuesSource, SumValueSource.canonicalDataType() would return "INT" and if you called SumValueSource's FunctionValues.intValue(docid) it would add up the results of the intValues() methods on all of the wrapped FunctionValues – but floatValues(docid) would/could still add up the results of the floatValue(docid) results from all of the wrapped FunctionValues (for people who want to coerce float based math – ie: SOLR-6574)
Attachments
Issue Links
- is related to
-
SOLR-6562 Function query calculates the wrong value
- Resolved
-
SOLR-6490 ValueSourceParser function "max" does not handle dates.
- Resolved
-
SOLR-6574 new ValueSources & parser syntax for "coercing" the datatypes used in wrapped ValueSources
- Open
-
LUCENE-5325 Move ValueSource and FunctionValues under core/
- Resolved