T - result typeQ - concrete subtypepublic abstract class AbstractJPAQuery<T,Q extends AbstractJPAQuery<T,Q>> extends JPAQueryBase<T,Q>
| 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 |
queryMixinMDC_PARAMETERS, MDC_QUERY| Constructor and Description |
|---|
AbstractJPAQuery(javax.persistence.EntityManager em) |
AbstractJPAQuery(javax.persistence.EntityManager em,
JPQLTemplates templates,
QueryMetadata metadata) |
| 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()
Get the projection as a typed List
|
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. |
T |
fetchOne()
Get the projection as a unique result or null if no result is found
|
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. |
com.mysema.commons.lang.CloseableIterator<T> |
iterate()
Get the projection as a typed closeable Iterator
|
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()
Get the projection as a typed closeable Stream.
|
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, toStringaccept, contains, contains, eq, eq, exists, getMetadata, getType, goe, goe, gt, gt, hashCode, in, in, isNotNull, isNull, loe, loe, lt, lt, ne, ne, notExistsequals, fetchFirst, transform, uniqueResultdistinct, groupBy, groupBy, having, having, limit, offset, orderBy, orderBy, restrict, set, where, wherefinalize, getClass, notify, notifyAll, wait, wait, waittransformfetchFirstdistinct, limit, offset, orderBy, restrict, setwherecontains, contains, eq, eq, exists, goe, goe, gt, gt, in, in, isNotNull, isNull, loe, loe, lt, lt, ne, ne, notExistsgetMetadataaccept, getTypeprotected final java.util.Map<java.lang.String,java.lang.Object> hints
protected final javax.persistence.EntityManager entityManager
protected final QueryHandler queryHandler
@Nullable protected @Nullable javax.persistence.LockModeType lockMode
@Nullable protected @Nullable javax.persistence.FlushModeType flushMode
@Nullable protected @Nullable FactoryExpression<?> projection
public AbstractJPAQuery(javax.persistence.EntityManager em)
public AbstractJPAQuery(javax.persistence.EntityManager em,
JPQLTemplates templates,
QueryMetadata metadata)
@Deprecated public long fetchCount()
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.fetch().size().public javax.persistence.Query createQuery()
protected javax.persistence.Query createQuery(@Nullable
@Nullable QueryModifiers modifiers,
boolean forCount)
public com.mysema.commons.lang.CloseableIterator<T> iterate()
Fetchablepublic java.util.stream.Stream<T> stream()
Fetchablepublic java.util.List<T> fetch()
Fetchablefetch in interface Fetchable<T>fetch in class FetchableQueryBase<T,Q extends AbstractJPAQuery<T,Q>>@Deprecated public QueryResults<T> fetchResults()
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.QueryResults form.
Make sure to use Fetchable.fetch() instead if you do not rely on the QueryResults.getOffset() or
QueryResults.getLimit(), because it will be more performant. Also, count queries cannot be
properly generated for all dialects. For example: in JPA count queries can't be generated for queries
that have multiple group by expressions or a having clause.
Get the projection in QueryResults form.
Use Fetchable.fetch() instead if you do not need the total count of rows in the query result.Fetchable.fetch()protected void logQuery(java.lang.String queryString)
protected void reset()
reset in class JPAQueryBase<T,Q extends AbstractJPAQuery<T,Q>>@Nullable public T fetchOne() throws NonUniqueResultException
FetchableNonUniqueResultException - if there is more than one matching resultpublic Q setLockMode(javax.persistence.LockModeType lockMode)
public Q setFlushMode(javax.persistence.FlushModeType flushMode)
public Q setHint(java.lang.String name, java.lang.Object value)
protected JPQLSerializer createSerializer()
createSerializer in class JPAQueryBase<T,Q extends AbstractJPAQuery<T,Q>>protected void clone(Q query)
public abstract Q clone(javax.persistence.EntityManager entityManager)
entityManager - entity managerpublic abstract Q clone(javax.persistence.EntityManager entityManager, JPQLTemplates templates)
entityManager - entity managertemplates - templatespublic Q clone()
clone in class JPAQueryBase<T,Q extends AbstractJPAQuery<T,Q>>Copyright © 2007–2021 Querydsl. All rights reserved.