VIATRA/Releases/MigrationTo1.3

Query specification registry

We have introduced a completely new Query Specification Registry and deprecated the old version. Users of the org.eclipse.viatra.query.runtime.extensibility.QuerySpecificationRegistry class should read the JavaDoc for details on how to migrate to the new org.eclipse.viatra.query.runtime.registry.QuerySpecificationRegistry implementation.

Read VIATRA/Query/UserDocumentation/API/Advanced#Query_specification_registry for details on the new registry.

Type inferrer in pattern language

The type inferrer of the VIATRA Query Language was rewritten; in most cases, it should behave exactly the same as the previous version, with the following differences:

• If some data types, such as strings or integers, are returned, sometimes the old inferrer calculated Object as its return type. The new version often calculates now the correct type. This behavior is presented by the calculation QualifiedName derived feature of UML Classifiers: in version 1.2, the name parameter returned Object, while in 1.3 it is correctly calculated as String.
• The variables of patterns are required to have a single, identifiable type during type inference. If required, the closest common supertype is calculated, however, if that is not unique for a parameter, an error is thrown. The old inferrer implementation in case of complex inheritance hierarchies sometimes did not detect that this closest common supertype is not unique, but selected one. In such cases, the new inferrer throws an error, requiring the parameter type to be declared manually. For these cases, a quick fix is available to insert any of the possible types manually.
• Known issue: in case of patterns with multiple check and eval expressions, the type inferrer is sometimes incapable of inferring the return types of eval expressions correctly inside other expressions. The error messages are a bit misleading, as the it is perfectly legit to enter an Object into a check expression, so only by an incorrectly typed expression is the issue detected.

The problem can be worked around using a typecast in the expression. See the following (artificial) example:

pattern t4_erroneous(n) {
  check(n > 2); //Error 1: '> cannot be resolved'; Error 2: 'Check expression must return boolean'
  n == eval(2);
}

pattern t4_fixed(n) {
  check((n as Integer)> 2);
  n == eval(2);
}