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.
Difference between revisions of "VIATRA/Releases/NewAndNoteworthy1.4"
(→Query development environment improvements) |
|||
Line 7: | Line 7: | ||
== Query language improvements == | == 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 <code>eval()</code> or (b) aggregation expression should be annotated with their Java types. Java type names can be referenced by prefixing them with the keyword <code>java</code>, and of course namespace imports are available. So, for example, a query parameter may be typed as follows: <code>prettyPrinted: java String</code>. Usage basics are explained in the [https://wiki.eclipse.org/VIATRA/Query/UserDocumentation/QueryLanguage#Pattern_Structure query language syntax guide]. | ||
+ | |||
+ | <source lang="java"> | ||
+ | pattern cpus(hi : HostInstance, no : java Integer) { | ||
+ | HostInstance.availableCpu(hi, no); | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | === Aggregators === | ||
In addition to the previously supported <code>count</code> keyword, there are now several new '''aggregators''' available (including <code>sum</code>, <code>min</code> and <code>max</code>, 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 [https://wiki.eclipse.org/VIATRA/Query/UserDocumentation/QueryLanguage#Advanced_Pattern_Constraints query language syntax guide]. | In addition to the previously supported <code>count</code> keyword, there are now several new '''aggregators''' available (including <code>sum</code>, <code>min</code> and <code>max</code>, 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 [https://wiki.eclipse.org/VIATRA/Query/UserDocumentation/QueryLanguage#Advanced_Pattern_Constraints query language syntax guide]. | ||
− | + | <source lang="java"> | |
+ | pattern sumCPUs(s : java Integer) { | ||
+ | s == sum find cpus(_hi2, #_); | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | === Parameter direction support === | ||
+ | |||
+ | Parameters can optionally be marked as incoming (<code>in</code>), outgoing (<code>out</code>). 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. | ||
+ | |||
+ | <source lang="java"> | ||
+ | pattern cpus(in hi : HostInstance, out no : java Integer) { | ||
+ | HostInstance.availableCpu(hi, no); | ||
+ | } | ||
+ | </source> | ||
+ | |||
+ | === Search engine declaration === | ||
+ | Patterns can optionally be declared either search-only (<code>search</code>) or Rete-only (<code>incremental</code>), 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. | ||
+ | |||
+ | <source lang="java"> | ||
+ | search pattern minCPUs(n : java Integer) { | ||
+ | n == min find cpus(_hi1, #_); | ||
+ | } | ||
− | + | incremental pattern sumCPUs(s : java Integer) { | |
− | + | s == sum find cpus(_hi2, #_); | |
− | + | } | |
+ | </source> | ||
== Query development environment improvements == | == Query development environment improvements == |
Revision as of 05:03, 28 September 2016
Contents
VIATRA 1.4 - New and Noteworthy
Local search support
- Planner and runtime
- Runtime configuration using hints
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: prettyPrinted: java String
. 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 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.
Some mentionable new features in the UI
- Show location works for queries, matchers, matches and parameter values
- Improved labeling in the tree (reuse domain specific icons for EMF model elements)
- Tree view for engine details including the model, engine options, base index options
- Match set filtering is possible through the Properties view
- 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
- Remove individual matchers from Query Results
Screenshots of the new UI
Transformation development perspective default layout:
Filtering matches from the Matcher properties:
Open managed engines into Query Results:
Details of managed engines to help selection:
Base indexer enhancements
* Wildcard mode can be set up later than construction * Statistical indexing
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.