Deprecated API

Contents

• Methods

Methods

Method	Description
com.querydsl.jpa.hibernate.StatelessSessionHolder.createQuery(String)
com.querydsl.jpa.hibernate.StatelessSessionHolder.createSQLQuery(String)
com.querydsl.jpa.impl.AbstractJPAQuery.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 AbstractJPAQuery.fetch(). For large result sets this may come at a severe performance penalty. For very specific domain models where AbstractJPAQuery.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.
com.querydsl.jpa.impl.AbstractJPAQuery.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 AbstractJPAQuery.fetch(). For large result sets this may come at a severe performance penalty. For very specific domain models where AbstractJPAQuery.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 AbstractJPAQuery.fetch() instead.
com.querydsl.jpa.JPQLTemplates.isEnumInPathSupported()