Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


Model Query Evaluation

VIATRA 1.6 provides a few new features that aim for better compatibility in a wider range of use cases. In general, VIATRA should work out of the box the same way it worked before, but there are some settings that allow a more finely tuned behaviour for certain situations.

Custom implementations of the EMF API (e.g. when generated code is manually modified) may violate EMF API contracts, and send incorrect notifications (e.g. duplicate model deletion events); similar situations can arise e.g. if there are custom EMF adapters that throw exceptions. In previous versions of VIATRA, this resulted in strange exceptions being thrown from the query backend. In version 1.6, the model indexer identifies most of these cases and provides a more precise error message describing what happens. It is also possible to tell the indexer to ignore (more specifically, log only) these incorrect notifications by turning the strict notification mode off, as shown below.

BaseIndexOptions options = new BaseIndexOptions().withStrictNotificationMode(false); 
ResourceSet rSet = new ResourceSetImpl();
EMFScope scope = new EMFScope(rSet, options);
ViatraQueryEngine engine = ViatraQueryEngine.on(scope);

In case of the query scope is set to a subset of the entire model (e.g only one EMF resource within the resource set), model elements within the scope of the engine may havereferences pointing to elements outside the scope; these are called dangling edges. Previous versions of VIATRA made the assumption that the model is self-contained and free of dangling edges; the behavior of the query engine was unspecified (potentially incorrect match sets) if the model did not have this property. In VIATRA 1.6, this behavior was cleaned up by adding a new indexer mode that drops this assumption, and (with a minor cost to performance) always checks both ends of all indexed edges to be in-scope. For backward compatibility, the old behavior is used by default, but you can manually change this using the corresponding base index option as below. For new code we suggest to use this option to drop the dangling-free assumption, as it provides more consistent and intuitive results in a lot of cases; in a future VIATRA release this will be the new default.

BaseIndexOptions options = new BaseIndexOptions().withDanglingFreeAssumption(false); 
ResourceSet rSet = new ResourceSetImpl();
EMFScope scope = new EMFScope(rSet, options);
ViatraQueryEngine engine = ViatraQueryEngine.on(scope);

The advanced query API now includes a feature that lets users temporarily "turn off" query result maintenance in the incremental query backend. During such a code block, only the base model indexer is updated, query results remain stale until the end of the block. The advantage is that it is possible to save significant execution time when changing the model in a way that partially undoes itself, e.g. a large part of the model is removed and then re-added.

AdvancedViatraQueryEngine engine = ...
engine.delayUpdatePropagation(new Callable<Void>() {
    public Void call() throws Exception {
        // perform extensive changes in model that largely cancel each other out
        return null;

Finally, VIATRA 1.6 includes the Delete and REDerive (DRed) algorithm as an experimental opt-in choice for evaluating recursive queries. Formerly, recursive queries were only fully supported under the condition that there can be circular dependencies between VQL patterns (or a pattern and itself), but not between individual matches of these patterns. Such circularity could lead to incorrect result maintenance after changes, even if all involved pattern calls are positive (simple find constraints). This restriction can now be relaxed by enabling DRed. With a small penalty in execution time, DRed guarantees correct result maintenance for arbitrary recursive pattern structures as long as all recursive calls are positive (i.e. no negation or aggregation along cycles of recursion). Note that for the very common special case of transitive closures, the dedicated language element (transitive pattern call) is still likely to be more efficient. DRed is still in an experimental phase, and is turned off by default; it can be manually enabled using the query evaluation hint ReteHintOptions.deleteRederiveEvaluation.

Code generator updates

VIATRA Query Codegen Options.png

For users targeting other environment than Eclipse plug-ins, it is now possible to disallow the updating of MANIFEST.MF and plugin.xml files. The bundle manifest is updated to ensure all packages that contain query specifications are exported, while plugin.xml files are used by the query specification registry to load all patterns during runtimes.

This setting is available as a workspace-level preference or a per-project setting. By default, these settings are turned on (so both files are updated on each build), maintaining compatibility with previous releases.

The other major change relates to the handling of private patterns. Given private patterns are not expected to be used outside calling them from patterns in the same vql file, the generated code does not need all the type-safe wrappers generated. However, to make private patterns testable using the query test API, the generated QuerySpecification classes were moved to a dedicated package were they could be made public without exporting them to all users of the query bundles.

In complex metamodels described in Ecore and genmodel files there are often cross-references between files with absolute or workspace-relative urls. When compiling VIATRA queries using the maven compiler, these urls cannot be resolved automatically. EMF uses URI converters to define a mapping between such source and target model elements. Starting with VIATRA 1.6, you can now specify the location of metamodels referred to via platform:/resource URIs with the uriMappings configuration element. See this wiki page for more details.

Query Test Framework updates

Viatra Query Coverage report.png

The query testing capabilities of VIATRA were extended to support a wider range of models and queries. This required new customization options for the test definition DSL, including support for non-default EMF resources as models and using more generic Java types in the query result snapshots. For a more detailed definitions of these features look at the documentation.

When testing your patterns, you can measure their test coverage (similar to what EclEmma does to Java code). This means you can see which constraints described in the patterns were used during the evaluation of the queries. The coverage can be reported as an HTML file which immediately shows which patterns need more testing. See the feature's documentation for details.

Documentation updates

VIATRA query explain message.png

To make it easier to get started with VIATRA, a tutorial is added that presents an example for query and transformation development. In order to make the tutorial available for even more users, this documentation is also included in the platform help.

A few error messages in the query editor related to enumerable and non-enumerable references had been reported to hard to understand. In this version the error messages have been updated, and a quick fix was also added that updates a detailed explanation for the message. In future versions we plan to extend this support to make other error messages more understandable.

GEF5-based visualization

VIATRA Rete Visualizer.png

The graph-based components, specifically the Rete visualizer, Local search debugger and the graph visualization support of Viewers, were updated to rely on the latest GEF version 5.0 (available with Eclipse Oxygen). This results in an updated, JavaFX based display and further bugfixes available for these components by default.

Following the dependencies of GEF5 to use these features in the future, JavaFX (available from Java 8) and e(fx)clipse is required to be installed.

Complex Event Processing

VIATRA CEP has previously supported event parameters for atomic events only. From now on, complex events can also be parameterized, with full support for event composition. Furthermore, query events are parameterized as well, the parameters being directly derived from the parameters of the referenced query.

For example, see these sample events here. Given the following query:

pattern hasContainer(contained: EClass, container: EClass) = {
	EClass.eStructuralFeatures(container, ref);
	EReference.containment(ref, true);
	EReference.eType(ref, contained);

We can define a parameterized query event and compose it into a parameterized complex event:

queryEvent addContainer(contained:EObject, container:EObject) 
	as hasContainer(contained, container) found
complexEvent addContainer2(cned:EObject, container1:EObject, container2:EObject) {
	as (addContainer(cned, container1) -> addContainer(cned, container2))

Design Space Exploration

VIATRA-DSE got a few incremental updates and bug fixes.

A new exploration algorithm called best-first search has been added that will eventually explore the whole design space (if it is finite of course) always continuing with the best possible choice. It can be instantiated with Strategies.createBestFirstStrategy(int maxDepth/*optional*/). It also has two configuration possibilities: .continueIfHardObjectivesFulfilled() (so it won't backtrack if a solution is found) and .goOnOnlyIfFitnessIsBetter() (so it won't explore equally good states immediately, only better ones). Currently it is implemented without multithreading.

The utility function DesignSpaceExplorer.saveModels(*) will save all solutions as EMF models. See API doc for details.

DepthHardObjective has been introduced that provides minimum and maximum depth criteria for solutions. Can be instantiated with Objectives.createDepthHardObjective().

Performance has been improved by a better backtracking mechanism: when an exploration strategy resets to an other trajectory for exploring other areas of the design space and if the new and the old trajectory start with the same rule applications, then it will only backtrack to their last common state.

Additional issues

For a complete list of fixed issues for VIATRA 1.6 consult

Back to the top