Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

VIATRA/Query/UserDocumentation/CustomAggregators

< VIATRA‎ | Query
Stop.png
Old information
This page is not updated anymore; for more up-to-date details look at the query language documentation at https://www.eclipse.org/viatra/documentation/query-language.html instead.

As of version 1.4, the Viatra Query ships with the following built-in aggregation operators:

  • count
  • sum
  • min
  • max

There is also a preliminary API for extending this set with your custom, user-defined aggregators. Important note: this API should be considered provisional, and will likely change in the future.

The first step is to provide a class that implements the Java interface IMultisetAggregationOperator by subclassing AbstractMultisetAggregationOperator. An instance of your class would represent a mathematical aggregation operator (independently of any context, such as patterns, variables, etc.) and provide incremental computation of the aggregate results from a changing multiset of values. Please read the Javadoc carefully to ensure that you meet all assumed contracts; you may also want to inspect the provided built-in implementors to gain a better understanding.

In order to actually use your aggregator in the query language, the second step is to provide an implementation of IAggregatorFactory that must be on the classpath of the query project in order to be accessible from queries. It is customary to take exception to Java naming conventions and use a lower-case class name, as the name of this class will be the aggregator operator name in the query language. The role of this class is twofold:

  • First, to provide type information to the query language via the annotation @AggregatorType. This is achieved by listing the acceptable types of aggregable values; and, in a separate list with the same order, the respective types of the aggregate result.
  • Second, to actually instantiate the previously implemented operator class(es) for a given context in a query. The returned operator implementation and its output type may depend on the type of the aggregated values.

Once again, please read the Javadoc carefully and take a look at the built-in implementations as well.

Back to the top