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


Viatra 2.0 Design Docs and Brainstorming, Fall 2017


Minimum dependencies

  • Java 8
  • Eclipse Mars
  • Xtext 2.12
  • Guava 21
  • Eclipse Collections 9

Components to keep or graduate:

Main points to address

  • Scoping and imports in VQL (breaking backward compatibility on query definitions)
  • Minimum dependency updates (see above)
  • Remove all deprecated API
  • Consider using runtime exceptions instead of checked exceptions
  • See list of issues in 2.0.0M1

Top priority until March 2018

  • Runtime API breaks
  • VQL2 language

Language design changes

  • Add file-level element that can receive annotations
  • Rethink public/private patterns
    • Let runtime know what is important for `Release` performance
    • Important for incremental engines: know what must be maintained, what can be flattened
  • Compositional sources of base relations (scopes)
    • Better support for non-EMF scopes
    • Better support for user-supplied relations, magic sets, traceability, etc.
    • Must be mixable as freely as possible
  • Minor syntactic sugar
    • graph-like mnemonic for unary and binary base relations
    • neg {local pattern}
    • neg BareType(notWrappedInHelperPattern)

Runtime design changes

  • API debt
    • Remove all deprecated API
    • Consider using runtime exceptions instead of checked exceptions
  • Compositional scopes to support associated language goal
  • User-supplied relations
    • VQ Engine owner shall be able to provide (through an easy API) the contents of custom relations that the query definitions can rely on
      • API1 to provide custom relations that realize the relevant IQMC, IQRC methods, including index lookup and notifications
      • API2 where index lookups are taken care of, contents and notifications are still provided by the user
      • API3 where these relations are implemented e.g. as a set (with indexer lookups, notifications, etc.), the user can call manipulation operations
    • Must be possible to add a posteriori to any other scope (e.g. EMF), see also compositional scopes
  • Do we need surrogate values in the EMF base index?
  • Rethink matcher API
    • In case of surrogates, remove types from API
    • Can Matches also be Tuples, or at least backed by them? Try to reduce (persistent and transient) duplication.
  • Distributed processing extensions
    •  ???

Back to the top