Package org.elasticsearch.search.aggregations.support

Class ValuesSource.Numeric

java.lang.Object

org.elasticsearch.search.aggregations.support.ValuesSource

org.elasticsearch.search.aggregations.support.ValuesSource.Numeric

Direct Known Subclasses:

GeoHashCellIdSource, GeoTileCellIdSource, ValuesSource.Numeric.FieldData, ValuesSource.Numeric.Script, ValuesSource.Numeric.WithScript

Enclosing class:

ValuesSource

public abstract static class ValuesSource.Numeric
extends ValuesSource

ValuesSource for fields who's values are best thought of as numbers. Aggregations that operate on these values often may chose to operate on double precision floating point values or on 64 bit signed two's complement values. They'll do normal "number stuff" to those values like add, multiply, and compare them to other numbers.

Nested Class Summary

Nested Classes

Modifier and Type	Class	Description
static class	ValuesSource.Numeric.FieldData
static class	ValuesSource.Numeric.Script	ValuesSource implementation for stand alone scripts returning a Numeric value
static class	ValuesSource.Numeric.WithScript	ValuesSource subclass for Numeric fields with a Value Script applied

Nested classes/interfaces inherited from class org.elasticsearch.search.aggregations.support.ValuesSource

ValuesSource.Bytes, ValuesSource.GeoPoint, ValuesSource.Numeric, ValuesSource.Range

Field Summary

Fields

Modifier and Type	Field	Description
static ValuesSource.Numeric	EMPTY

Constructor Summary

Constructors

Constructor	Description
Numeric()

Method Summary

Modifier and Type	Method	Description
DocValueBits	docsWithValue(org.apache.lucene.index.LeafReaderContext context)	Get a "has any values" view into the values.
abstract SortedNumericDoubleValues	doubleValues(org.apache.lucene.index.LeafReaderContext context)	Get a double precision floating point view into the values in this leaf.
abstract boolean	isFloatingPoint()	Are values of this field better represented as a double precision floating point numbers (true) or 64 bit signed numbers (false)?
abstract org.apache.lucene.index.SortedNumericDocValues	longValues(org.apache.lucene.index.LeafReaderContext context)	Get a 64 bit signed view into the values in this leaf.
Function<Rounding,Rounding.Prepared>	roundingPreparer()	Build a function to prepare Roundings.

Methods inherited from class org.elasticsearch.search.aggregations.support.ValuesSource

bytesValues, hasOrdinals, needsScores

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Details

EMPTY

public static final ValuesSource.Numeric EMPTY

Constructor Details

Numeric

public Numeric()

Method Details

isFloatingPoint

public abstract boolean isFloatingPoint()

Are values of this field better represented as a double precision floating point numbers (true) or 64 bit signed numbers (false)?

Aggregations may, if they feel it is important, use this to pick which of longValues(org.apache.lucene.index.LeafReaderContext) and doubleValues(org.apache.lucene.index.LeafReaderContext) is better for the field values. Most metric aggregations are quite happy to operate on floating point numbers all the time and never call this. Bucketing aggregations that want to enumerate all values (like TermsAggregator) will want to check this but bucketing aggregations that just compare values (RangeAggregator) are, like metric aggregators, fine ignoring it.

longValues

public abstract org.apache.lucene.index.SortedNumericDocValues longValues(org.apache.lucene.index.LeafReaderContext context)
                                                                   throws IOException

Get a 64 bit signed view into the values in this leaf.

If the values have precision beyond the decimal point then they'll be "narrowed" but they'll accurately represent values up to Long.MAX_VALUE.

Throws:

IOException

doubleValues

public abstract SortedNumericDoubleValues doubleValues(org.apache.lucene.index.LeafReaderContext context)
                                                throws IOException

Get a double precision floating point view into the values in this leaf.

These values will preserve any precision beyond the decimal point but are limited to double's standard 53 bit mantissa. If the "native" field has values that can't be accurately represented in those 53 bits they'll be "widened"

Throws:

IOException

docsWithValue

public DocValueBits docsWithValue(org.apache.lucene.index.LeafReaderContext context)
                           throws IOException

Description copied from class: ValuesSource

Get a "has any values" view into the values. It'll try to pick the "most native" way to check if there are any values, but it builds its own view into the values so if you need any of the actual values its best to use something like ValuesSource.bytesValues(org.apache.lucene.index.LeafReaderContext) or doubleValues(org.apache.lucene.index.LeafReaderContext) but if you just need to know if there are any values then use this.

Specified by:

docsWithValue in class ValuesSource

Throws:

IOException

roundingPreparer

public Function<Rounding,Rounding.Prepared> roundingPreparer()
                                                      throws IOException

Description copied from class: ValuesSource

Build a function to prepare Roundings.

This returns a Function because auto date histogram will need to call it many times over the course of running the aggregation. Other aggregations should feel free to call it once.

Specified by:

roundingPreparer in class ValuesSource

Throws:

IOException