Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

VIATRA/Query/DeveloperDocumentation/QueryEngineArchitecture

IncQuery Engine Internals

Overview

IncQueryEngine.png

Most important concepts

  • IncQueryEngine: the central element of the API.
  • IncQueryScope: selects the model the IncQueryEngine should work on. The project itself implements only EMFScope right now.
  • RuntimeContext: wrapper class for the query backends to access the model. The access can be both indexed and non-indexed.
  • IQueryBackend: an executor of graph pattern matches; it instantiates IResultProviders. Query Backends needs to be registered to the IncQueryEngine itself.
    • RetePatternMatcher is the fully incremental implementation of the IResultProvider interface.
    • LocalSearchMatcher is a local search based implementation of the IResultProvider interface.
  • The Matcher interface is the public matcher API: generated instances are type-safe.

EngineConfiguration Proposal 2015-10-19

Here is a proposal for an (internal) API overhaul that restructures the way backend selection and hints are indicated.

Goals

  • Make sure that (managed) IQ engines can have a configurable query backend that they use for all queries - unless specified otherwise - see Bug 466336
  • Ensure that we can make available some preconfigured packages of backend implementation + corresponding evaluation hints, that correspond to good choices in common workloads
  • Make sure that there is no need to manually register backend classes (even outside the plugin.xml environment)
  • Remain open for further extensions (new aspects of the engine to configure) with maximized API stability

Proposed Solution

  • In analogy with BaseIndexOptions, there should be an (immutable) IncQueryEngineConfiguration or IncQueryEngineOptions class (which can be extended in the future with further options).
    • The configuration object contains a QueryEvaluationHint field, setting the default query backend and default evaluation options the engine uses for all of its queries. It is, of course still possible to override these manually for each query.
      • The configuration object may provide additional fields (e.g. is engine strictly restricted to its default backend?), TBD before the 1.2 release.
      • If future versions add more options, only this configuration class has to be modified; the engine creation API retains its signature.
    • When creating an unmanaged engine, such a configuration object can be given along with the scope.
      • If the parameter is omitted, a static default options object is used (reproducing the original default behaviour).
      • The default engineConfig is always used for managed engines, since it is currently not possible to accommodate for conflicting preferences of multiple users within a single shared engine instance.
    • Apart from the default config, additional "typical configurations" can be provided as public static final fields. For most users interested in non-default engine modes (e.g. using Local Search as the main backend, with EMF-specific ops and planning), we can just point them to create their engine with such a preconfigured profile, and then do not worry about giving more specific hints on a query-by-query basis.
  • To abolish the need for registering backends, each backend type should be identified by its factory rather than by its class.
    • The field of QueryEvaluationHint that specifies the recommended backend should be of type IQueryBackendFactory instead of Class<? extends IQueryBackend>.
    • When creating a hint, the query backend factory should be used instead of the query backend class, e.g. ReteEngine.FACTORY instead of ReteEngine.class. Such (static) factory instances must be publicly available to identify query evaluator implementations.
    • There is no class --> factory lookup, so nothing has to be registered. QueryBackendRegistry, at least in its current form, can be deleted / made deprecated.
  • Miscellaneous tasks
    • Ideally, we should investigate moving the hint management subsystem of IQE into a separate class contained within the engine, to shrink the monolith somewhat.
    • Massive Javadoc fix / revision needed, e.g. for IQueryBackend and *Factory.

Back to the top