Deprecated API

Contents

• Deprecated Classes
• Deprecated Fields
• Deprecated Methods
• Deprecated Constructors

Deprecated Classes

Class and Description
com.querydsl.core.util.JavaSyntaxUtils use the built-in keyword list instead.

Deprecated Fields

Field and Description
com.querydsl.sql.SQLOps.FOR_SHARE_FLAG
com.querydsl.sql.SQLOps.FOR_UPDATE_FLAG
com.querydsl.sql.SQLOps.NO_WAIT_FLAG

Deprecated Methods

Method and Description
com.querydsl.sql.codegen.NamingStrategy.appendSchema(String, String) Use NamingStrategy.getPackage(String, SchemaAndTable) instead.
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.sql.codegen.NamingStrategy.getClassName(String) Use NamingStrategy.getClassName(SchemaAndTable) instead.
com.querydsl.sql.codegen.ant.AntMetaDataExporter.getCustomTypes() Use addCustomType instead
com.querydsl.sql.AbstractSQLQuery.getResults(Expression<?>...) Use @{code select(..)} to define the projection and getResults() to obtain the result set
com.querydsl.codegen.EntityType.getUncapSimpleName()
com.querydsl.jpa.JPQLTemplates.isEnumInPathSupported()
com.querydsl.sql.Union.list() Use Fetchable.fetch()
com.querydsl.sql.Configuration.registerColumnOverride(String, String, String) Use Configuration.setDynamicNameMapping(NameMapping) instead.
com.querydsl.sql.Configuration.registerColumnOverride(String, String, String, String) Use Configuration.setDynamicNameMapping(NameMapping) instead.
com.querydsl.sql.Configuration.registerSchemaOverride(String, String) Use Configuration.setDynamicNameMapping(NameMapping) instead.
com.querydsl.sql.Configuration.registerTableOverride(SchemaAndTable, SchemaAndTable) Use Configuration.setDynamicNameMapping(NameMapping) instead.
com.querydsl.sql.Configuration.registerTableOverride(String, String) Use Configuration.setDynamicNameMapping(NameMapping) instead.
com.querydsl.sql.Configuration.registerTableOverride(String, String, String) Use Configuration.setDynamicNameMapping(NameMapping) instead.
com.querydsl.sql.Configuration.registerTableOverride(String, String, String, String) Use Configuration.setDynamicNameMapping(NameMapping) instead.
com.querydsl.sql.codegen.ant.AntMetaDataExporter.setCustomTypes(String[]) Use addCustomType instead
com.querydsl.codegen.GenericExporter.setHandleFields(boolean) Use GenericExporter.setPropertyHandling(PropertyHandling) instead
com.querydsl.codegen.GenericExporter.setHandleMethods(boolean) Use GenericExporter.setPropertyHandling(PropertyHandling) instead
com.querydsl.core.support.SerializerBase.setNormalize(boolean) normalization happens now at template level
com.querydsl.sql.codegen.MetaDataExporter.setSchemaToPackage(boolean) This flag will not be necessary in the future because the generated package name can be controlled in method NamingStrategy.getPackage(String, SchemaAndTable).

Deprecated Constructors

Constructor and Description
com.querydsl.apt.DefaultConfiguration(ProcessingEnvironment, RoundEnvironment, Collection<String>, Class<? extends Annotation>, Class<? extends Annotation>, Class<? extends Annotation>, Class<? extends Annotation>, Class<? extends Annotation>, Class<? extends Annotation>, CodegenModule)
com.querydsl.apt.DefaultConfiguration(RoundEnvironment, Map<String, String>, Collection<String>, Class<? extends Annotation>, Class<? extends Annotation>, Class<? extends Annotation>, Class<? extends Annotation>, Class<? extends Annotation>, Class<? extends Annotation>)
com.querydsl.core.types.Template.OperationConst(int, BigDecimal, Operator, boolean)
com.querydsl.sql.SQLTemplates(String, char, boolean)