Semantic MediaWiki and related extensions
Public Member Functions | List of all members
SMW\SQLStore\QueryEngine\QueryEngine Class Reference
Collaboration diagram for SMW\SQLStore\QueryEngine\QueryEngine:
Collaboration graph
[legend]

Public Member Functions

 __construct (SQLStore $store, QuerySegmentListBuildManager $querySegmentListBuildManager, QuerySegmentListProcessor $querySegmentListProcessor, EngineOptions $engineOptions)
 
 setLogger (LoggerInterface $logger)
 
 getQueryResult (Query $query)
 

Detailed Description

Class that implements query answering for SQLStore.

GNU GPL v2+

Since
2.2
Author
Markus Krötzsch
Jeroen De Dauw
mwjames

Constructor & Destructor Documentation

SMW\SQLStore\QueryEngine\QueryEngine::__construct ( SQLStore  $store,
QuerySegmentListBuildManager  $querySegmentListBuildManager,
QuerySegmentListProcessor  $querySegmentListProcessor,
EngineOptions  $engineOptions 
)
Since
2.2
Parameters
SQLStore$store
QuerySegmentListBuildManager$querySegmentListBuildManager
QuerySegmentListProcessor$querySegmentListProcessor
EngineOptions$engineOptions

Member Function Documentation

SMW\SQLStore\QueryEngine\QueryEngine::getQueryResult ( Query  $query)

The new SQL store's implementation of query answering. This function works in two stages: First, the nested conditions of the given query object are preprocessed to compute an abstract representation of the SQL query that is to be executed. Since query conditions correspond to joins with property tables in most cases, this abstract representation is essentially graph-like description of how property tables are joined. Moreover, this graph is tree-shaped, since all query conditions are tree-shaped. Each part of this abstract query structure is represented by an QuerySegment object in the array querySegmentList.

As a second stage of processing, the thus prepared SQL query is actually executed. Typically, this means that the joins are collapsed into one SQL query to retrieve results. In some cases, such as in dbug mode, the execution might be restricted and not actually perform the whole query.

The two-stage process helps to separate tasks, and it also allows for better optimisations: it is left to the execution engine how exactly the query result is to be obtained. For example, one could pre-compute partial suib-results in temporary tables (or even cache them somewhere), instead of passing one large join query to the DB (of course, it might be large only if the configuration of SMW allows it). For some DBMS, a step-wise execution of the query might lead to better performance, since it exploits the tree-structure of the joins, which is important for fast processing – not all DBMS might be able in seeing this by themselves.

Parameters
Query$query
Returns
mixed depends on $query->querymode

Implements SMW\QueryEngine.

SMW\SQLStore\QueryEngine\QueryEngine::setLogger ( LoggerInterface  $logger)
See also
LoggerAwareInterface::setLogger
Since
2.5
Parameters
LoggerInterface$logger

The documentation for this class was generated from the following file: