Package com.querydsl.jpa.impl

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

    • Field Detail

      • hints

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

      • entityManager

        protected final jakarta.persistence.EntityManager entityManager

      • lockMode

        @Nullable
protected @Nullable jakarta.persistence.LockModeType lockMode

      • flushMode

        @Nullable
protected @Nullable jakarta.persistence.FlushModeType flushMode

    • Constructor Detail

      • AbstractJPAQuery

        public AbstractJPAQuery​(jakarta.persistence.EntityManager em)

      • AbstractJPAQuery

        public AbstractJPAQuery​(jakarta.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 (&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 jakarta.persistence.Query createQuery()
        Expose the original JPA query for the given projection
        Returns:
        query

      • createQuery

        protected jakarta.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()

      • 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​(java.lang.String queryString)

      • setLockMode

        public Q setLockMode​(jakarta.persistence.LockModeType lockMode)

      • setFlushMode

        public Q setFlushMode​(jakarta.persistence.FlushModeType flushMode)

      • setHint

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

      • clone

        protected void clone​(Q query)

      • clone

        public abstract Q clone​(jakarta.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​(jakarta.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