Class BuiltInAggregateFunction<T,ACC>
- java.lang.Object
-
- org.apache.flink.table.functions.UserDefinedFunction
-
- org.apache.flink.table.functions.ImperativeAggregateFunction<T,ACC>
-
- org.apache.flink.table.functions.AggregateFunction<T,ACC>
-
- org.apache.flink.table.runtime.functions.aggregate.BuiltInAggregateFunction<T,ACC>
-
- All Implemented Interfaces:
Serializable
,FunctionDefinition
- Direct Known Subclasses:
ArrayAggFunction
,BatchApproxCountDistinctAggFunctions.ApproxCountDistinctAggFunction
,CollectAggFunction
,FirstValueAggFunction
,FirstValueWithRetractAggFunction
,JsonArrayAggFunction
,JsonObjectAggFunction
,LagAggFunction
,LastValueAggFunction
,LastValueWithRetractAggFunction
,ListAggWithRetractAggFunction
,ListAggWsWithRetractAggFunction
,MaxWithRetractAggFunction
,MinWithRetractAggFunction
,PercentileAggFunction
@Internal public abstract class BuiltInAggregateFunction<T,ACC> extends AggregateFunction<T,ACC>
Base class for runtime implementation represented asAggregateFunction
that is constructed fromBuiltInFunctionDefinition.specialize(SpecializedContext)
.Subclasses must offer a constructor that takes
SpecializedFunction.SpecializedContext
if they are constructed from aBuiltInFunctionDefinition
. Otherwise theBuiltInAggregateFunction()
constructor might be more appropriate.By default, all built-in functions work on internal data structures. However, this can be changed by overriding
getArgumentDataTypes()
,getAccumulatorDataType()
, andgetOutputDataType()
. Or by overridinggetTypeInference(DataTypeFactory)
directly.Since the accumulator type is runtime specific, it must be declared explicitly; otherwise it is derived from the output type.
- See Also:
- Serialized Form
-
-
Constructor Summary
Constructors Modifier Constructor Description protected
BuiltInAggregateFunction()
protected
BuiltInAggregateFunction(BuiltInFunctionDefinition definition, SpecializedFunction.SpecializedContext context)
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description DataType
getAccumulatorDataType()
List<DataType>
getArgumentDataTypes()
DataType
getOutputDataType()
Set<FunctionRequirement>
getRequirements()
Returns the set of requirements this definition demands.TypeInference
getTypeInference(DataTypeFactory typeFactory)
Returns the logic for performing type inference of a call to this function definition.boolean
isDeterministic()
Returns information about the determinism of the function's results.-
Methods inherited from class org.apache.flink.table.functions.AggregateFunction
getKind, getValue
-
Methods inherited from class org.apache.flink.table.functions.ImperativeAggregateFunction
createAccumulator, getAccumulatorType, getResultType
-
Methods inherited from class org.apache.flink.table.functions.UserDefinedFunction
close, functionIdentifier, open, toString
-
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
-
Methods inherited from interface org.apache.flink.table.functions.FunctionDefinition
supportsConstantFolding
-
-
-
-
Constructor Detail
-
BuiltInAggregateFunction
protected BuiltInAggregateFunction(BuiltInFunctionDefinition definition, SpecializedFunction.SpecializedContext context)
-
BuiltInAggregateFunction
protected BuiltInAggregateFunction()
-
-
Method Detail
-
getAccumulatorDataType
public DataType getAccumulatorDataType()
-
getOutputDataType
public DataType getOutputDataType()
-
getTypeInference
public TypeInference getTypeInference(DataTypeFactory typeFactory)
Description copied from class:UserDefinedFunction
Returns the logic for performing type inference of a call to this function definition.The type inference process is responsible for inferring unknown types of input arguments, validating input arguments, and producing result types. The type inference process happens independent of a function body. The output of the type inference is used to search for a corresponding runtime implementation.
Instances of type inference can be created by using
TypeInference.newBuilder()
.See
BuiltInFunctionDefinitions
for concrete usage examples.The type inference for user-defined functions is automatically extracted using reflection. It does this by analyzing implementation methods such as
eval() or accumulate()
and the generic parameters of a function class if present. If the reflective information is not sufficient, it can be supported and enriched withDataTypeHint
andFunctionHint
annotations.Note: Overriding this method is only recommended for advanced users. If a custom type inference is specified, it is the responsibility of the implementer to make sure that the output of the type inference process matches with the implementation method:
The implementation method must comply with each
DataType.getConversionClass()
returned by the type inference. For example, ifDataTypes.TIMESTAMP(3).bridgedTo(java.sql.Timestamp.class)
is an expected argument type, the method must accept a calleval(java.sql.Timestamp)
.Regular Java calling semantics (including type widening and autoboxing) are applied when calling an implementation method which means that the signature can be
eval(java.lang.Object)
.The runtime will take care of converting the data to the data format specified by the
DataType.getConversionClass()
coming from the type inference logic.- Specified by:
getTypeInference
in interfaceFunctionDefinition
- Overrides:
getTypeInference
in classAggregateFunction<T,ACC>
-
getRequirements
public Set<FunctionRequirement> getRequirements()
Description copied from interface:FunctionDefinition
Returns the set of requirements this definition demands.
-
isDeterministic
public boolean isDeterministic()
Description copied from interface:FunctionDefinition
Returns information about the determinism of the function's results.It returns
true
if and only if a call to this function is guaranteed to always return the same result given the same parameters.true
is assumed by default. If the function is not purely functional likerandom(), date(), now(), ...
this method must returnfalse
.Furthermore, return
false
if the planner should always execute this function on the cluster side. In other words: the planner should not perform constant expression reduction during planning for constant calls to this function.
-
-