Class SqlQueryContext<S,Q extends FlexibleRelationalPathBase<R>,R>

java.lang.Object
com.evolveum.midpoint.repo.sqlbase.SqlQueryContext<S,Q,R>
Type Parameters:
S - schema type, used by encapsulated mapping
Q - type of entity path
R - row type related to the SqlQueryContext
All Implemented Interfaces:
FilterProcessor<ObjectFilter>
Direct Known Subclasses:
SqaleQueryContext

public abstract class SqlQueryContext<S,Q extends FlexibleRelationalPathBase<R>,R> extends Object implements FilterProcessor<ObjectFilter>
Execution context of the SQL query. Works as a kind of accumulator where information are added as the object query is interpreted. The object has a couple of overlapping responsibilities: * It implements FilterProcessor and is used as an entry point for filter processing for the query. * It executes the query, returning PageOf low-level rows, see executeQuery(com.evolveum.midpoint.repo.sqlbase.JdbcSession). * It transforms the row beans to midPoint objects using transformToSchemaType(com.evolveum.midpoint.repo.sqlbase.PageOf<com.querydsl.core.Tuple>, com.evolveum.midpoint.repo.sqlbase.JdbcSession). QueryTableMapping is crucial for all these steps and flow of the execution goes a lot between the SqlQueryExecutor, this class and particular methods of the mapping. Anything specific for a particular type/table should be part of the mapping logic. The mapping contract should cover all the needs of this execution context. It can be extended if needed, but always think whether existing mechanisms are not enough already. E.g. if you need to post-process the low level result, there is a way how to do it and it allows for things like loading all the detail table rows in a single query. See transformToSchemaType(com.evolveum.midpoint.repo.sqlbase.PageOf<com.querydsl.core.Tuple>, com.evolveum.midpoint.repo.sqlbase.JdbcSession) for notes how this allows for inter-row state keeping as well. [NOTE] Implementation note: There was an option to keep this as an information accumulator only and do the execution elsewhere, but it proved more practical to utilize all the contained parameterized types. Methods executing the query and processing the result would need to be parameterized the same way this context already is - so it was better to use the types here. [NOTE] This object does not handle SQL connections or transaction in any way, any connection needed is provided from the outside.