Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VIATRA/Query/UserDocumentation/CustomAggregators"

< VIATRA‎ | Query
 
Line 1: Line 1:
{{caution|Old information|This page is not updated anymore; for more up-to-date details look at the query api documentation at https://www.eclipse.org/viatra/documentation/query-api.html instead.}}
+
{{caution|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:
 
As of version 1.4, the Viatra Query ships with the following built-in aggregation operators:
 
* count
 
* count

Latest revision as of 15:27, 14 November 2017

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