|
|
| (3 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | == IncQuery Engine Internals == | + | == VIATRA Query Engine Internals == |
| | | | |
| | === Overview === | | === Overview === |
| Line 6: |
Line 6: |
| | === Most important concepts === | | === Most important concepts === |
| | | | |
| − | * '''IncQueryEngine''': the central element of the API. | + | * '''ViatraQueryEngine''': the central element of the API. |
| − | * '''IncQueryScope''': selects the model the IncQueryEngine should work on. The project itself implements only EMFScope right now. | + | * '''QueryScope''': the set of model elements the ViatraQueryEngine should work on. |
| − | * '''RuntimeContext''': wrapper class for the query backends to access the model. The access can be both indexed and non-indexed. | + | ** The project itself implements only '''EMFScope''' right now. |
| − | * '''IQueryBackend''': an executor of graph pattern matches; it instantiates IResultProviders. Query Backends needs to be registered to the IncQueryEngine itself. | + | * '''IQueryRuntimeContext''': wrapper class for the query backends to access the model. The access can be both indexed and non-indexed. |
| − | ** '''RetePatternMatcher''' is the fully incremental implementation of the IResultProvider interface. | + | * '''IQueryBackend''': an executor of graph pattern matches; it instantiates '''IQueryResultProvider'''s. Query Backends needs to be registered to the ViatraQueryEngine itself. |
| − | ** '''LocalSearchMatcher''' is a local search based implementation of the IResultProvider interface. | + | ** '''RetePatternMatcher''' is the fully incremental implementation of the '''IQueryResultProvider''' interface. |
| − | * The '''Matcher''' interface is the public matcher API: generated instances are type-safe. | + | ** '''LocalSearchResultProvider''' is a local search based implementation of the '''IQueryResultProvider''' interface. |
| − | | + | * The '''ViatraQueryMatcher''' 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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=466336 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.
| + | |
| − | *** '''EDIT 2015-11-03''': As B. Grill pointed out today, retaining a list of available backend implementations would still be useful for the Query Explorer UI, if not for the engine runtime. So I now suggest retaining a registry solely for this purpose. However, registration can be completely automated by the extension mechanism, since the registry is now used in the Eclipse environment only. The registry can still be placed in the "matchers" plug-in, so that backends can automatically register to it.
| + | |
| − | * 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 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.
| + | |
