VIATRA/DeveloperDocumentation/EngineConfigurationProposal

• Overview
• Queries
• Transformation
• CEP
• DSE
• Integrations
• Addons
• Contributors Guide
• Releases

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) query engines can have a configurable query backend that they use for all queries - unless specified otherwise - see bug 466336 and bug 491172
• 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

Engine Configuration Options

• In analogy with BaseIndexOptions, there should be an (immutable) ViatraQueryEngineConfiguration or ViatraQueryEngineOptions class (which can be extended in the future with further options) (see bug 491172).
  • 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.

Update backend registration

• To abolish the need for registering backends, each backend type should be identified by its factory rather than by its class. Fixed in bug 466336
  • 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.
    • The Query Explorer component maintains an internal registry of available backend implementations. In VIATRA 1.2, the list is hardcoded; in the future more implementations might be added e.g. via extension points.

Miscellaneous tasks

• Discuss how we could provide options to backends that are not specific to an individual query, but apply to the whole backend instance.
  • Hijack the hint system for this as well? The backend can then look up the engine default hints for such global options; this can be done upon initialization, before even getting the first query.
  • Use non-static factories that can be parameterized by these arguments? This is problematic, as generated query specifications with generated hints will not be able to know in advanced how to get the specific instance of the factory.
• Ideally, we should investigate moving the hint management subsystem of the query engine into a separate class contained within the engine, to shrink the monolith somewhat.
  • Massive Javadoc fix / revision needed, e.g. for IQueryBackend and *Factory.