Revision as of 11:02, 21 March 2016

Overview

This page overviews advanced use-cases for VIATRA Query. The topics cover

• the Generic API, to be used when the features supported by the generated API do not suffice (e.g. when working with dynamically defined patterns, or patterns whose handles are not known at compile time)
• Advanced change processing APIs, and advanced lifecycle management techniques to be used for performance-critical and/or resource-constrained applications
• VIATRA Query Base, the low-level query and indexer layer underneath VIATRA Query pattern matchers
• logging in VIATRA Query, which is provided by hierarchic Log4J loggers.

The VIATRA Query Generic API

The "generic" API differs from the generated one in two key aspects:

• it can be used to apply queries and use other VIATRA Query features without generating code and loading the resulting bundles into the running configuration. In other words, you just need to supply the EMF-based in-memory representation (an instance of the Pattern class)
• the generic API is not "type safe" in the sense that the Java types of your pattern variables is not known and needs to be handled dynamically (e.g. by instanceof - typecase combos).

Initializing matchers and accessing results

Sample code

Using the Generic API:

public String executeDemo_GenericAPI_LoadFromEIQ(String modelPath, String patternFQN) {
  final StringBuilder results = new StringBuilder();
  Resource resource = loadModel(modelPath);
  if (resource != null) {
    try {
      // get all matches of the pattern
      // create an *unmanaged* engine to ensure that noone else is going
      // to use our engine
      AdvancedIncQueryEngine engine = AdvancedIncQueryEngine.createUnmanagedEngine(resource);
      // instantiate a pattern matcher through the registry, by only knowing its FQN
      // assuming that there is a pattern definition registered matching 'patternFQN'
 
      Pattern p = null;
 
      // Initializing Xtext-based resource parser
      // Do not use if VIATRA Query tooling is loaded!
      new EMFPatternLanguageStandaloneSetup().createInjectorAndDoEMFRegistration();
 
      //Loading pattern resource from file
      ResourceSet resourceSet = new ResourceSetImpl();
      URI fileURI = URI.createPlatformPluginURI("headlessQueries.incquery/src/headless/headlessQueries.eiq", false);
      Resource patternResource = resourceSet.getResource(fileURI, true);
 
      // navigate to the pattern definition that we want
      if (patternResource != null) {
        if (patternResource.getErrors().size() == 0 && patternResource.getContents().size() >= 1) {
          EObject topElement = patternResource.getContents().get(0);
          if (topElement instanceof PatternModel) {
            for (Pattern _p  : ((PatternModel) topElement).getPatterns()) {
              if (patternFQN.equals(CorePatternLanguageHelper.getFullyQualifiedName(_p))) {
                p = _p; break;
              }
            }
          }
        }
      }
      if (p == null) {
        throw new RuntimeException(String.format("Pattern %s not found", patternFQN));
      }
      // A specification builder is used to translate patterns to query specifications
      SpecificationBuilder builder = new SpecificationBuilder();
 
      // attempt to retrieve a registered query specification		    
      IncQueryMatcher<? extends IPatternMatch> matcher = engine.getMatcher(builder.getOrCreateSpecification(p));
 
      if (matcher!=null) {
        Collection<? extends IPatternMatch> matches = matcher.getAllMatches();
        prettyPrintMatches(results, matches);
      }
 
      // wipe the engine
      engine.wipe();
      // after a wipe, new patterns can be rebuilt with much less overhead than 
      // complete traversal (as the base indexes will be kept)
 
      // completely dispose of the engine once's it is not needed
      engine.dispose();
      resource.unload();
    } catch (IncQueryException e) {
      e.printStackTrace();
      results.append(e.getMessage());
    }
  } else {
    results.append("Resource not found");
  }
  return results.toString();
}

API interfaces

• IPatternMatch
  • reflection: pattern(), patternName()
  • getters and setters
  • utility functions (toArray, prettyPrint)
• IncQueryMatcher
  • reflection
  • get all matches
  • get single/arbitrary match
  • check for a match
  • number of matches
  • process matches
  • access change processing features
  • create a new Match for input binding
  • access projected value sets

The Pattern Registry and Matcher Factories

TODO The IMatcherFactory interface

• reflection
• initialize the matcher

Advanced query result set change processing

The Event-driven VM can be used for this purpose. See the section called "Efficiently reacting to pattern match set changes".

Advanced VIATRA Query Lifecycle management

Managed vs. unmanaged IncQueryEngines

Disposing

If you want to remove the matchers from the engine you can call the wipe() method on it. It discards any pattern matcher caches and forgets the known patterns. The base index built directly on the underlying EMF model, however, is kept in memory to allow reuse when new pattern matchers are built. If you don’t want to use it anymore call the dispose() instead, to completely disconnect and dismantle the engine.

VIATRA Query Base

VIATRA Query provides a light-weight indexer library called Base that aims to provide several useful (some would even argue critical) features for querying EMF models:

• inverse navigation along EReferences
• finding and incrementally tracking all model elements by attribute value/type (i.e. inverse navigation along EAttributes)
• incrementally computing transitive reachability along given reference types (i.e. transitive closure of an EMF model)
• getting and tracking all the (direct) instances of a given EClass

The point of VIATRA Query Base is to provide all of these in an incremental way, which means that once the query evaluator is attached to an EMF model, as long as it stays attached, the query results can be retrieved instantly (as the query result cache is automatically updated). VIATRA Query Base is a lightweight, small Java library that can be integrated easily to any EMF-based tool as it can be used in a stand-alone way, without the rest of VIATRA Query.

We are aware that some of the functionality can be found in some Ecore utility classes (for example ECrossReferenceAdapter). These standard implementations are non-incremental, and are thus do not scale well in scenarios where high query evaluation performance is necessary (such as e.g. on-the-fly well-formedness validation or live view maintenance). VIATRA Query Base has an additional important feature that is not present elsewhere: it contains very efficient implementations of transitive closure that can be used e.g. to maintain reachability regions incrementally, in very large EMF instance models.

The detailed documentation is covered in EMFIncQuery/UserDocumentation/API/BaseIndexer

Extracting reachability paths from transitive closure

Beyond the support for querying reachability information between nodes in the model, the TransitiveClosureHelper class also provides the functionality to retrieve paths between pairs of nodes. The getPathFinder method returns an IGraphPathFinder object, which exposes the following operations:

Deque<V> getPath(V sourceNode, V targetNode): Returns an arbitrary path from the source node to the target node (if such exists).
Iterable<Deque<V>> getShortestPaths(V sourceNode, V targetNode): Returns the collection of shortest paths from the source node to the target node (if such exists).
Iterable<Deque<V>> getAllPaths(V sourceNode, V targetNode): Returns the collection of paths from the source node to the target node (if such exists).
Iterable<Deque<V>> getAllPathsToTargets(V sourceNode, Set<V> targetNodes): Returns the collection of paths from the source node to any of the target nodes (if such exists).

Internally these operations use a depth-first-search traversal and rely on the information which is incrementally maintained by the transitive closure component.

Logging in VIATRA Query

VIATRA Query logs error messages and some trace information using log4j. If you need to debug your application and would like to see these messages, you can set the log level in different hierarchy levels. Since we use standard log4j, you can configure logging both with configuration files or through API calls.

• All loggers are children of a top-level default logger, that can be accessed from IncQueryLoggingUtil.getDefaultLogger(), just call setLevel(Level.DEBUG) on the returned logger to see all messages (of course you can use other levels as well).
• Each engine has it's own logger that is shared with the Base Index and the matchers as well. If you want to see all messages related to all engines, call IncQueryLoggingUtil.getLogger(IncQueryEngine.class) and set the level.
• Some other classes also use their own loggers and the same approach is used, they get the loggers based on their class, so retrieving that logger and setting the level will work as well.

Configuration problems

log4j uses a properties file as a configuration for its root logger. However, since this configuration is usually supplied by developers of applications, we do not package it in VIATRA Query. This means you may encounter the following on your console if no configuration was supplied:

log4j:WARN No appenders could be found for logger (org.eclipse.viatra.query.runtime.util.ViatraQueryLoggingUtil).
log4j:WARN Please initialize the log4j system properly.

There are several cases where this can occur:

• You have Xtext SDK installed, which has a plugin fragment called org.eclipse.xtext.logging that supplies a log4j configuration. Make sure that the fragment is selected in your Runtime Configuration.
• You are using the tooling of VIATRA Query without the Xtext SDK, you will see the above warning, but since the patternlanguage.emf plugins also inject appenders to the loggers of VIATRA Query, log messages will be correctly displayed.
• You are using only the runtime part of VIATRA Query that has no Xtext dependency. You have to provide your own properties file (standalone execution) or fragment (OSGi execution), see http://www.eclipsezone.com/eclipse/forums/t99588.html
• Alternatively, if you just want to make sure that log messages appear in the console no matter what other configuration happens, you can call IncQueryLoggingUtil.setupConsoleAppenderForDefaultLogger() which will do exactly what its name says. Since appenders and log levels are separate, you will still have to set the log level on the loggers you want to see messages from.
• If you wish to completely turn the logger of, call IncQueryLoggingUtil.getDefaultLogger().setLevel(Level.OFF);.

Using Filtered Input Models During Pattern Matching

In several cases it is beneficial to not include all Resources from a ResourceSet during pattern matching, but consider more than one. Such cases might include Xtext/Xbase languages or JaMoPP[1]-based instances that include resources representing the classes of the Java library.

VIATRA Query includes some options to filter out some subtrees from being indexed both by the Base Indexer and the Rete networks, by providing a filter implementation to the VIATRA Query Engine. These options include the IBaseIndexResourceFilter and IBaseIndexObjectFilter instances that can be used to filter out entire resources or containment subtrees, respectively.

Sample usage (by filtering out Java classes referred by JaMoPP):

ResourceSet resourceSet = ...; //Use a Resource Set as the root of the engine 
BaseIndexOptions options = new BaseIndexOptions().withResourceFilterConfiguration(new IBaseIndexResourceFilter() {
 
  @Override
  public boolean isResourceFiltered(Resource resource) {
    // PathMap URI scheme is used to refer to JDK classes
    return "pathmap".equals(resource.getURI().scheme());
  }
});
//Initializing scope with custom options
EMFScope scope = new EMFScope(resourceSet, options);
IncQueryEngine engine = IncQueryEngine.on(scope);

Important! there are some issues to be considered while using this API:

• If a Resource or containment subtree is filtered out, it is filtered out entirely. It is not possible to re-add some lower-level contents.
• There is a known issue with result matches that are only partially in the filtered area. Be careful with queried edges that are connecting filtered and non-filtered elements. See bug 398907 for details.

Using alternative search algorithms

Since version 0.9, there is a possibility to refer to alternative search engines in addition to Rete-based incremental engines; version 1.0 includes a local search based search algorithm usable with the VIATRA Query matcher API.

The most important steps to perform:

• Add a dependency to the optional plug-in org.eclipse.viatra.query.runtime.localsearch
• Explicitly ask for a local search-based matcher when initializing the matcher instance:

IQuerySpecification<?> specification = ...;
QueryEvaluationHint hint = new QueryEvaluationHint(LocalSearchBackendFactory.INSTANCE, Collections.emptyMap());
AdvancedViatraQueryEngine.from(queryEngine).getMatcher(specification, hint);

• After initialization, the existing pattern matcher API constructs can be used over the local search engine.

Parameterizing local search

Parameterization of the planner algorithm is possible via the hinting mechanism. In the current release three hint keys are provided for this purpose in the LocalSearchHintKeys class:

• • USE_BASE_INDEX: allow/disallow the usage of the index. Its value may be true or false. Currently the default is true.
  • ALLOW_INVERSE_NAVIGATION: allow/disallow inverse navigation along EReferences without an EOpposite. Its value may be true or false. Currently the default is true.
  • PLANNER_TABLE_ROW_COUNT: An internal parameter, bigger values often mean longer plan generation times, and potentially search plans with lower cost. Its value may be a positive int, the default is 4 in this release.

For example, to disable the use of base index, provide a hint with the key USE_BASE_INDEX with value false:

IQuerySpecification<?> specification = ...;
HashMap<String, Object> mapForHint = Maps.<String, Object>newHashMap();
mapForHint.put(LocalSearchHintKeys.USE_BASE_INDEX,false);
// Other hints may be added to the map here
QueryEvaluationHint hint = new QueryEvaluationHint(LocalSearchBackend.class, mapForHint);
AdvancedIncQueryEngine.from(engine).getMatcher(specification, hint);

Known limitations

• A local search matcher cannot provide change notifications on pattern matches. If asked, an UnsupportedOperationException is thrown.
• For now, it is not possible to combine different pattern matching algorithms. Either the entire search must use Rete or Local search based algorithms.
• Currently, local search always creates new plans from scratch, saving and reusing plans is not implemented yet.