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 forTableRelationResolver
TS
- schema type for the target entity, can be owning container or objectTQ
- type of target entity pathTR
- row type related to the target entity pathTableRelationResolver
- 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
Modifier and TypeFieldDescriptionprotected final BiFunction<Q,
TQ, com.querydsl.core.types.Predicate> protected final Supplier<QueryTableMapping<TS,
TQ, TR>> -
Constructor Summary
ModifierConstructorDescriptionprotected
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 TypeMethodDescriptionmapping()
replaceTable
(QueryTableMapping<? extends TS, TQ, TR> target) resolve
(SqlQueryContext<?, Q, R> context, boolean parent) Creates the EXISTS subquery using provided query context.resolveUsingJoin
(SqlQueryContext<?, Q, R> 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) Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Methods inherited from interface com.evolveum.midpoint.repo.sqlbase.mapping.ItemRelationResolver
resolve
-
Field Details
-
targetMappingSupplier
protected final Supplier<QueryTableMapping<TS,TQ extends FlexibleRelationalPathBase<TR>, targetMappingSupplierTR>> -
correlationPredicateFunction
protected final BiFunction<Q extends FlexibleRelationalPathBase<R>,TQ extends FlexibleRelationalPathBase<TR>, correlationPredicateFunctioncom.querydsl.core.types.Predicate>
-
-
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
-
usingSubquery
public static <Q extends FlexibleRelationalPathBase<R>,R, TableRelationResolver<Q,TS, TQ extends FlexibleRelationalPathBase<TR>, TR> R, usingSubqueryTS, TQ, TR> (@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, TableRelationResolver<Q,TS, TQ extends FlexibleRelationalPathBase<TR>, TR> R, usingJoinTS, TQ, TR> (@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 inItemRelationResolver.resolve(SqlQueryContext)
, perhaps accessible via the context parameter. -
resolve
public ItemRelationResolver.ResolutionResult<TQ,TR> resolve(SqlQueryContext<?, Q, R> context, boolean parent) Creates the EXISTS subquery using provided query context.- Specified by:
resolve
in interfaceItemRelationResolver<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
-
resolveUsingJoin
public ItemRelationResolver.ResolutionResult<TQ,TR> resolveUsingJoin(SqlQueryContext<?, Q, R> context) - Specified by:
resolveUsingJoin
in interfaceItemRelationResolver<Q extends FlexibleRelationalPathBase<R>,
R, TS, TQ extends FlexibleRelationalPathBase<TR>>
-
replaceTable
public TableRelationResolver<Q,R, replaceTableTS, TQ, TR> (QueryTableMapping<? extends TS, TQ, TR> target) -
withSubquery
-
reverse
public <AQ extends FlexibleRelationalPathBase<AR>,AS, TableRelationResolver<TQ,AR> TR, reverseAS, AQ, AR> (@NotNull @NotNull QueryTableMapping<AS, AQ, AR> targetMapping) -
mapping
-