com.querydsl.jpa.impl

Class AbstractJPAQuery<T,Q extends AbstractJPAQuery<T,Q>>

java.lang.Object

com.querydsl.core.support.QueryBase<Q>

com.querydsl.core.support.FetchableQueryBase<T,Q>

com.querydsl.core.support.FetchableSubQueryBase<T,Q>

com.querydsl.jpa.JPAQueryBase<T,Q>

com.querydsl.jpa.impl.AbstractJPAQuery<T,Q>

Type Parameters:

T - result type

Q - concrete subtype

All Implemented Interfaces:

Fetchable<T>, FetchableQuery<T,JPQLQuery<T>>, FilteredClause<JPQLQuery<T>>, Query<JPQLQuery<T>>, SimpleQuery<JPQLQuery<T>>, ExtendedSubQuery<T>, Expression<T>, SubQueryExpression<T>, JPQLQuery<T>, java.io.Serializable

Direct Known Subclasses:

JPAQuery

public abstract class AbstractJPAQuery<T,Q extends AbstractJPAQuery<T,Q>>
extends JPAQueryBase<T,Q>

Abstract base class for JPA API based implementations of the JPQLQuery interface

Author:

tiwe

See Also:

Serialized Form

Field Summary

Fields

Modifier and Type	Field and Description
protected javax.persistence.EntityManager	entityManager
protected @Nullable javax.persistence.FlushModeType	flushMode
protected java.util.Map<java.lang.String,java.lang.Object>	hints
protected @Nullable javax.persistence.LockModeType	lockMode
protected @Nullable FactoryExpression<?>	projection
protected QueryHandler	queryHandler

Fields inherited from class com.querydsl.jpa.JPAQueryBase

queryMixin

Fields inherited from class com.querydsl.core.support.QueryBase

MDC_PARAMETERS, MDC_QUERY

Constructor Summary

Constructors

Constructor and Description
AbstractJPAQuery(javax.persistence.EntityManager em)
AbstractJPAQuery(javax.persistence.EntityManager em, JPQLTemplates templates, QueryMetadata metadata)

Method Summary

Modifier and Type	Method and Description
Q	clone() Clone the state of this query to a new instance
abstract Q	clone(javax.persistence.EntityManager entityManager) Clone the state of this query to a new instance with the given EntityManager
abstract Q	clone(javax.persistence.EntityManager entityManager, JPQLTemplates templates) Clone the state of this query to a new instance with the given EntityManager and the specified templates
protected void	clone(Q query)
javax.persistence.Query	createQuery() Expose the original JPA query for the given projection
protected javax.persistence.Query	createQuery(@Nullable QueryModifiers modifiers, boolean forCount)
protected JPQLSerializer	createSerializer()
java.util.List<T>	fetch()
long	fetchCount() Deprecated. fetchCount requires a count query to be computed. In querydsl-sql, this is done by wrapping the query in a subquery, like so: SELECT COUNT(*) FROM (&lt;original query&gt;). Unfortunately, JPQL - the query language of JPA - does not allow queries to project from subqueries. As a result there isn't a universal way to express count queries in JPQL. Historically QueryDSL attempts at producing a modified query to compute the number of results instead. However, this approach only works for simple queries. Specifically queries with multiple group by clauses and queries with a having clause turn out to be problematic. This is because COUNT(DISTINCT a, b, c), while valid SQL in most dialects, is not valid JPQL. Furthermore, a having clause may refer select elements or aggregate functions and therefore cannot be emulated by moving the predicate to the where clause instead. In order to support fetchCount for queries with multiple group by elements or a having clause, we generate the count in memory instead. This means that the method simply falls back to returning the size of fetch(). For large result sets this may come at a severe performance penalty. For very specific domain models where fetchCount() has to be used in conjunction with complex queries containing multiple group by elements and/or a having clause, we recommend using the Blaze-Persistence integration for QueryDSL. Among other advanced query features, Blaze-Persistence makes it possible to select from subqueries in JPQL. As a result the BlazeJPAQuery provided with the integration, implements fetchCount properly and always executes a proper count query.
T	fetchOne()
QueryResults<T>	fetchResults() Deprecated. fetchResults requires a count query to be computed. In querydsl-sql, this is done by wrapping the query in a subquery, like so: SELECT COUNT(*) FROM (&lt;original query&gt;). Unfortunately, JPQL - the query language of JPA - does not allow queries to project from subqueries. As a result there isn't a universal way to express count queries in JPQL. Historically QueryDSL attempts at producing a modified query to compute the number of results instead. However, this approach only works for simple queries. Specifically queries with multiple group by clauses and queries with a having clause turn out to be problematic. This is because COUNT(DISTINCT a, b, c), while valid SQL in most dialects, is not valid JPQL. Furthermore, a having clause may refer select elements or aggregate functions and therefore cannot be emulated by moving the predicate to the where clause instead. In order to support fetchResults for queries with multiple group by elements or a having clause, we generate the count in memory instead. This means that the method simply falls back to returning the size of fetch(). For large result sets this may come at a severe performance penalty. For very specific domain models where fetchResults() has to be used in conjunction with complex queries containing multiple group by elements and/or a having clause, we recommend using the Blaze-Persistence integration for QueryDSL. Among other advanced query features, Blaze-Persistence makes it possible to select from subqueries in JPQL. As a result the BlazeJPAQuery provided with the integration, implements fetchResults properly and always executes a proper count query. Mind that for any scenario where the count is not strictly needed separately, we recommend to use fetch() instead.
com.mysema.commons.lang.CloseableIterator<T>	iterate()
protected void	logQuery(java.lang.String queryString)
protected void	reset()
Q	setFlushMode(javax.persistence.FlushModeType flushMode)
Q	setHint(java.lang.String name, java.lang.Object value)
Q	setLockMode(javax.persistence.LockModeType lockMode)
java.util.stream.Stream<T>	stream()

Methods inherited from class com.querydsl.jpa.JPAQueryBase

fetchAll, fetchJoin, from, from, from, getTemplates, innerJoin, innerJoin, innerJoin, innerJoin, innerJoin, innerJoin, join, join, join, join, join, join, leftJoin, leftJoin, leftJoin, leftJoin, leftJoin, leftJoin, on, on, rightJoin, rightJoin, rightJoin, rightJoin, rightJoin, rightJoin, serialize, serialize, toString

Methods inherited from class com.querydsl.core.support.FetchableSubQueryBase

accept, contains, contains, eq, eq, exists, getMetadata, getType, goe, goe, gt, gt, hashCode, in, in, isNotNull, isNull, loe, loe, lt, lt, ne, ne, notExists

Methods inherited from class com.querydsl.core.support.FetchableQueryBase

equals, fetchFirst, transform, uniqueResult

Methods inherited from class com.querydsl.core.support.QueryBase

distinct, groupBy, groupBy, having, having, limit, offset, orderBy, orderBy, restrict, set, where, where

Methods inherited from class java.lang.Object

finalize, getClass, notify, notifyAll, wait, wait, wait

Methods inherited from interface com.querydsl.jpa.JPQLQuery

select, select

Methods inherited from interface com.querydsl.core.FetchableQuery

transform

Methods inherited from interface com.querydsl.core.Fetchable

fetchFirst

Methods inherited from interface com.querydsl.core.Query

groupBy, having

Methods inherited from interface com.querydsl.core.SimpleQuery

distinct, limit, offset, orderBy, restrict, set

Methods inherited from interface com.querydsl.core.FilteredClause

where

Methods inherited from interface com.querydsl.core.support.ExtendedSubQuery

contains, contains, eq, eq, exists, goe, goe, gt, gt, in, in, isNotNull, isNull, loe, loe, lt, lt, ne, ne, notExists

Methods inherited from interface com.querydsl.core.types.SubQueryExpression

getMetadata

Methods inherited from interface com.querydsl.core.types.Expression

accept, getType

Field Detail

hints

protected final java.util.Map<java.lang.String,java.lang.Object> hints

entityManager

protected final javax.persistence.EntityManager entityManager

queryHandler

protected final QueryHandler queryHandler

lockMode

@Nullable
protected @Nullable javax.persistence.LockModeType lockMode

flushMode

@Nullable
protected @Nullable javax.persistence.FlushModeType flushMode

projection

@Nullable
protected @Nullable FactoryExpression<?> projection

Constructor Detail

AbstractJPAQuery

public AbstractJPAQuery(javax.persistence.EntityManager em)

AbstractJPAQuery

public AbstractJPAQuery(javax.persistence.EntityManager em,
                        JPQLTemplates templates,
                        QueryMetadata metadata)

Method Detail

fetchCount

@Deprecated
public long fetchCount()

Deprecated. fetchCount requires a count query to be computed. In querydsl-sql, this is done by wrapping the query in a subquery, like so: SELECT COUNT(*) FROM (<original query>). Unfortunately, JPQL - the query language of JPA - does not allow queries to project from subqueries. As a result there isn't a universal way to express count queries in JPQL. Historically QueryDSL attempts at producing a modified query to compute the number of results instead.

However, this approach only works for simple queries. Specifically queries with multiple group by clauses and queries with a having clause turn out to be problematic. This is because COUNT(DISTINCT a, b, c), while valid SQL in most dialects, is not valid JPQL. Furthermore, a having clause may refer select elements or aggregate functions and therefore cannot be emulated by moving the predicate to the where clause instead.

In order to support fetchCount for queries with multiple group by elements or a having clause, we generate the count in memory instead. This means that the method simply falls back to returning the size of fetch(). For large result sets this may come at a severe performance penalty.

For very specific domain models where fetchCount() has to be used in conjunction with complex queries containing multiple group by elements and/or a having clause, we recommend using the Blaze-Persistence integration for QueryDSL. Among other advanced query features, Blaze-Persistence makes it possible to select from subqueries in JPQL. As a result the BlazeJPAQuery provided with the integration, implements fetchCount properly and always executes a proper count query.

createQuery

public javax.persistence.Query createQuery()

Expose the original JPA query for the given projection

Returns:

query

createQuery

protected javax.persistence.Query createQuery(@Nullable
                                              @Nullable QueryModifiers modifiers,
                                              boolean forCount)

iterate

public com.mysema.commons.lang.CloseableIterator<T> iterate()

stream

public java.util.stream.Stream<T> stream()

fetch

public java.util.List<T> fetch()

Specified by:

fetch in interface Fetchable<T>

Overrides:

fetch in class FetchableQueryBase<T,Q extends AbstractJPAQuery<T,Q>>

fetchResults

@Deprecated
public QueryResults<T> fetchResults()

Deprecated. fetchResults requires a count query to be computed. In querydsl-sql, this is done by wrapping the query in a subquery, like so: SELECT COUNT(*) FROM (<original query>). Unfortunately, JPQL - the query language of JPA - does not allow queries to project from subqueries. As a result there isn't a universal way to express count queries in JPQL. Historically QueryDSL attempts at producing a modified query to compute the number of results instead.

However, this approach only works for simple queries. Specifically queries with multiple group by clauses and queries with a having clause turn out to be problematic. This is because COUNT(DISTINCT a, b, c), while valid SQL in most dialects, is not valid JPQL. Furthermore, a having clause may refer select elements or aggregate functions and therefore cannot be emulated by moving the predicate to the where clause instead.

In order to support fetchResults for queries with multiple group by elements or a having clause, we generate the count in memory instead. This means that the method simply falls back to returning the size of fetch(). For large result sets this may come at a severe performance penalty.

For very specific domain models where fetchResults() has to be used in conjunction with complex queries containing multiple group by elements and/or a having clause, we recommend using the Blaze-Persistence integration for QueryDSL. Among other advanced query features, Blaze-Persistence makes it possible to select from subqueries in JPQL. As a result the BlazeJPAQuery provided with the integration, implements fetchResults properly and always executes a proper count query.

Mind that for any scenario where the count is not strictly needed separately, we recommend to use fetch() instead.

logQuery

protected void logQuery(java.lang.String queryString)

reset

protected void reset()

Specified by:

reset in class JPAQueryBase<T,Q extends AbstractJPAQuery<T,Q>>

fetchOne

@Nullable
public T fetchOne()
                     throws NonUniqueResultException

Throws:

NonUniqueResultException

setLockMode

public Q setLockMode(javax.persistence.LockModeType lockMode)

setFlushMode

public Q setFlushMode(javax.persistence.FlushModeType flushMode)

setHint

public Q setHint(java.lang.String name,
                 java.lang.Object value)

createSerializer

protected JPQLSerializer createSerializer()

Specified by:

createSerializer in class JPAQueryBase<T,Q extends AbstractJPAQuery<T,Q>>

clone

protected void clone(Q query)

clone

public abstract Q clone(javax.persistence.EntityManager entityManager)

Clone the state of this query to a new instance with the given EntityManager

Parameters:

entityManager - entity manager

Returns:

cloned query

clone

public abstract Q clone(javax.persistence.EntityManager entityManager,
                        JPQLTemplates templates)

Clone the state of this query to a new instance with the given EntityManager and the specified templates

Parameters:

entityManager - entity manager

templates - templates

Returns:

cloned query

clone

public Q clone()

Clone the state of this query to a new instance

Specified by:

clone in class JPAQueryBase<T,Q extends AbstractJPAQuery<T,Q>>

Returns:

cloned query