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/Releases/NewAndNoteworthy1.4

Local search support during query evaluation

In version 1.4 the previously introduced local search support was greatly enhanced: several bugs and performance issues were fixed, while better integration is provided with the rest of VIATRA Query. In version 1.4 the planner and runtime is considered ready for production use, while future enhancements are still planned for future versions.

For this version, we already have performance benchmark that shows that local search based pattern matching can provide comparable performance during model transformation to Rete while requiring much less memory.

Viatra benchmark ls time.png

For more detailed documentation see VIATRA/Query/UserDocumentation/API/LocalSearch

Query language improvements

Java type references

The query language now allows Java type constraints, both as parameter types and as variable type constraints in pattern bodies. The recommended use case is that query parameters that are a result of (a) an eval() or (b) aggregation expression should be annotated with their Java types. Java type names can be referenced by prefixing them with the keyword java, and of course namespace imports are available. So, for example, a query parameter may be typed as follows: no: java Integer. Usage basics are explained in the query language syntax guide.

pattern cpus(hi : HostInstance, no : java Integer) {
	HostInstance.availableCpu(hi, no);
}

Aggregators

In addition to the previously supported count keyword, there are now several new aggregators available (including sum, min and max, as well as an API for user-defined aggregators) to compute an aggregated value from matches of a called pattern. Usage basics are explained in the query language syntax guide.

pattern sumCPUs(s : java Integer) {
	s == sum find cpus(_hi2, #_);
}

Parameter direction support

Parameters can optionally be marked as incoming (in), outgoing (out). Incoming parameters must be bound when the pattern matcher initializes, while outgoing parameters must not. For backwards compatibility, unmarked parameters are neither incoming nor outgoing: they might be either bound or unbound when called. In version 1.4, parameter directions are ignored by the Rete engine, but used by the local search engine to decide the set of plans to create during matcher preparation.

pattern cpus(in hi : HostInstance, out no : java Integer) {
	HostInstance.availableCpu(hi, no);
}

Search engine declaration

Patterns can optionally be declared either local search-only (search) or Rete-only (incremental), providing hints to the runtime what pattern matcher should be initialized for this pattern. If undefined, the default hints of the engine is used (by default, Rete); and can be redefined using the advanced query engine API.

It is important to note that the Query Engine may override these declarations, e.g. if they cannot be executed.

search pattern minCPUs(n : java Integer) {
	n == min find cpus(_hi1, #_);
}
 
incremental pattern sumCPUs(s : java Integer) {
	s == sum find cpus(_hi2, #_);
}

Query development environment improvements

We have graduated the completely new query development views that replace the Query Explorer. These views were introduced as part of VIATRA 1.3 (blog post with video) together with the Transformation Development perspective. For this release, we aimed to include all important features in the new views that were only available through the Query Explorer before (bug 499995 lists the relevant issues). If you already have the perspective opened, we recommend resetting it (right click on the perspective icon and select "Reset") as we have moved the views around to make more sense.

VIATRA-Query-UI-Registry-Results-Model-Engine details.png

The most important new features are as follows:

  • Show location works for queries, matchers, matches and parameter values
  • Improved labeling in the tree (reuse domain specific icons for EMF model elements)
  • Match set filtering is possible through the Properties view

VIATRA-Query-UI-Matcher filter.png

  • Drag-and-drop and double click for loading from Query Registry into Query Results
  • HiDPI icons for high-resolution, scaled displays.
  • Load existing managed query engines into the Query Results view

VIATRA-Query-UI-Open managed engine.png

  • Tree view for engine details including the model, engine options, base index options

VIATRA-Query-UI-Managed engine selection.png

  • Remove individual matchers from Query Results


Base indexer enhancements

In version 1.4, the Base Indexer was enhanced in a few ways:

  • Wildcard mode can be set up later than construction: an existing base indexer can now be asked to index everything in the model
  • Statistical indexing: instead of indexing model instances, Base can now only store model statistics. This is highly beneficial for local search, as for plan generation these statistics are very useful, but require less memory.

These enhancements are mostly useful in the query runtime (and were motivated by the requirements of local search), but are available for external uses as well.

Design Space Explorer enhancements

  • Method for setting the logging level: OFF, WARN, BASIC, VERBOSE_STRATEGY and VERBOSE_FULL
  • If the exploration is started asynchronously, it can be stopped by these methods: stopExploration(), stopExplorationAsync(), waitForTerminaition().
  • The evolutionary exploration strategy now can run on with multiple threads.
  • Depth first search strategy can continue exploration from a solution.
  • Minor performance enhancements.
  • Updated documentation on the wiki and also in the code: https://wiki.eclipse.org/VIATRA/DSE/UserGuide/API

Other issues

Version 1.4 also features a large number of under-the-hood changes, the most important is an updated hint system to enable fine-grained parametrization of the query engines. Usually, this change should be invisible for existing users; for possible migration issues see the Migration Guide.

In total more, than 70 issues were fixed in this release, see https://projects.eclipse.org/projects/modeling.viatra/releases/1.4.0/bugs for details.

Back to the top