Class AbstractJPAQuery<T,Q extends 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>, 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:
  • Field Details

    • hints

      protected final Map<String,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 Details

    • AbstractJPAQuery

      public AbstractJPAQuery(javax.persistence.EntityManager em)
    • AbstractJPAQuery

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

    • 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 (&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.
    • 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 Stream<T> stream()
    • fetch

      public 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 (&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.
    • logQuery

      protected void logQuery(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(String name, 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