Package com.evolveum.midpoint.repo.sqlbase.mapping

Class TableRelationResolver<Q extends FlexibleRelationalPathBase<R>,R,TS,TQ extends FlexibleRelationalPathBase<TR>,TR>

java.lang.Object

com.evolveum.midpoint.repo.sqlbase.mapping.TableRelationResolver<Q,R,TS,TQ,TR>

Type Parameters:

Q - type of source entity path (where the mapping is)

R - row type for TableRelationResolver

TS - schema type for the target entity, can be owning container or object

TQ - type of target entity path

TR - row type related to the target entity path TableRelationResolver

All Implemented Interfaces:

ItemRelationResolver<Q,R,TQ,TR>

Direct Known Subclasses:

ContainerTableRelationResolver

public class TableRelationResolver<Q extends FlexibleRelationalPathBase<R>,R,TS,TQ extends FlexibleRelationalPathBase<TR>,TR>
extends Object
implements ItemRelationResolver<Q,R,TQ,TR>

Resolver that knows how to traverse to the specified target query type. By default, EXISTS subquery is used which is better for multi-value table stored items to avoid result multiplication. The resolver supports mapping supplier to avoid call cycles during mapping initialization.

Nested Class Summary

Nested classes/interfaces inherited from interface com.evolveum.midpoint.repo.sqlbase.mapping.ItemRelationResolver

ItemRelationResolver.ResolutionResult<TQ extends FlexibleRelationalPathBase<TR>,TR>

Field Summary

Fields

Modifier and Type	Field	Description
protected final BiFunction<Q,TQ,com.querydsl.core.types.Predicate>	correlationPredicateFunction
protected final Supplier<QueryTableMapping<TS,TQ,TR>>	targetMappingSupplier

Constructor Summary

Constructors

Modifier	Constructor	Description
protected	TableRelationResolver(@NotNull QueryTableMapping<TS,TQ,TR> targetMapping, @NotNull BiFunction<Q,TQ,com.querydsl.core.types.Predicate> correlationPredicateFunction)	Constructor for relation resolver using `EXISTS` subquery to the table.

Method Summary

Modifier and Type	Method	Description
Supplier<QueryTableMapping<TS,TQ,TR>>	getTargetMappingSupplier()
QueryTableMapping<TS,TQ,TR>	mapping()
TableRelationResolver<Q,R,TS,TQ,TR>	replaceTable(QueryTableMapping<? extends TS,TQ,TR> target)
ItemRelationResolver.ResolutionResult<TQ,TR>	resolve(SqlQueryContext<?,Q,R> context)	Creates the EXISTS subquery using provided query context.
<AQ extends FlexibleRelationalPathBase<AR>, AS, AR> TableRelationResolver<TQ,TR,AS,AQ,AR>	reverse(@NotNull QueryTableMapping<AS,AQ,AR> targetMapping)
static <Q extends FlexibleRelationalPathBase<R>, R, TS, TQ extends FlexibleRelationalPathBase<TR>, TR> TableRelationResolver<Q,R,TS,TQ,TR>	usingJoin(@NotNull Supplier<QueryTableMapping<TS,TQ,TR>> targetMappingSupplier, @NotNull BiFunction<Q,TQ,com.querydsl.core.types.Predicate> correlationPredicateFunction)	Currently the decision to use `JOIN` is static in the mapping, but it can be more flexible.
static <Q extends FlexibleRelationalPathBase<R>, R, TS, TQ extends FlexibleRelationalPathBase<TR>, TR> TableRelationResolver<Q,R,TS,TQ,TR>	usingSubquery(@NotNull QueryTableMapping<TS,TQ,TR> targetMapping, @NotNull BiFunction<Q,TQ,com.querydsl.core.types.Predicate> correlationPredicateFunction)
TableRelationResolver<Q,R,TS,TQ,TR>	withSubquery()

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Details

targetMappingSupplier

protected final Supplier<QueryTableMapping<TS,TQ extends FlexibleRelationalPathBase<TR>,TR>> targetMappingSupplier

correlationPredicateFunction

protected final BiFunction<Q extends FlexibleRelationalPathBase<R>,TQ extends FlexibleRelationalPathBase<TR>,com.querydsl.core.types.Predicate> correlationPredicateFunction

Constructor Details

TableRelationResolver

protected TableRelationResolver(@NotNull
 @NotNull QueryTableMapping<TS,TQ,TR> targetMapping,
 @NotNull
 @NotNull BiFunction<Q,TQ,com.querydsl.core.types.Predicate> correlationPredicateFunction)

Constructor for relation resolver using `EXISTS` subquery to the table. This is good for multi-value containers.

Method Details

getTargetMappingSupplier

public Supplier<QueryTableMapping<TS,TQ,TR>> getTargetMappingSupplier()

usingSubquery

public static <Q extends FlexibleRelationalPathBase<R>,
R,
TS,
TQ extends FlexibleRelationalPathBase<TR>,
TR>
TableRelationResolver<Q,R,TS,TQ,TR> usingSubquery(@NotNull
 @NotNull QueryTableMapping<TS,TQ,TR> targetMapping,
 @NotNull
 @NotNull BiFunction<Q,TQ,com.querydsl.core.types.Predicate> correlationPredicateFunction)

usingJoin

public static <Q extends FlexibleRelationalPathBase<R>,
R,
TS,
TQ extends FlexibleRelationalPathBase<TR>,
TR>
TableRelationResolver<Q,R,TS,TQ,TR> usingJoin(@NotNull
 @NotNull Supplier<QueryTableMapping<TS,TQ,TR>> targetMappingSupplier,
 @NotNull
 @NotNull BiFunction<Q,TQ,com.querydsl.core.types.Predicate> correlationPredicateFunction)

Currently the decision to use `JOIN` is static in the mapping, but it can be more flexible. If the query does not order by such a path, `EXISTS` is more efficient and should be used. This would require order examination first and then using this info in resolve(SqlQueryContext), perhaps accessible via the context parameter.

resolve

public ItemRelationResolver.ResolutionResult<TQ,TR> resolve(SqlQueryContext<?,Q,R> context)

Creates the EXISTS subquery using provided query context.

Specified by:

resolve in interface ItemRelationResolver<Q extends FlexibleRelationalPathBase<R>,R,TS,TQ extends FlexibleRelationalPathBase<TR>>

Parameters:

context - query context used for subquery creation

Returns:

result with context for subquery entity path and its mapping

replaceTable

public TableRelationResolver<Q,R,TS,TQ,TR> replaceTable(QueryTableMapping<? extends TS,TQ,TR> target)

withSubquery

public TableRelationResolver<Q,R,TS,TQ,TR> withSubquery()

reverse

public <AQ extends FlexibleRelationalPathBase<AR>,
AS,
AR>
TableRelationResolver<TQ,TR,AS,AQ,AR> reverse(@NotNull
 @NotNull QueryTableMapping<AS,AQ,AR> targetMapping)

mapping

public QueryTableMapping<TS,TQ,TR> mapping()