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:
CellIdSource, 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.

  • Field Details

  • 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 java.io.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:
      java.io.IOException

    • doubleValues

      public abstract SortedNumericDoubleValues doubleValues​(org.apache.lucene.index.LeafReaderContext context) throws java.io.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:
      java.io.IOException

    • docsWithValue

      public DocValueBits docsWithValue​(org.apache.lucene.index.LeafReaderContext context) throws java.io.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:
      java.io.IOException

    • roundingPreparer

      public java.util.function.Function<Rounding,​Rounding.Prepared> roundingPreparer() throws java.io.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:
      java.io.IOException