public Interface QuerySettings

When enabled, specifies that Hibernate should attempt to map parameter names given in a org.hibernate.procedure.ProcedureCall or jakarta.persistence.StoredProcedureQuery to named parameters of the JDBC java.sql.CallableStatement.

Since

6.0

See Also

org.hibernate.boot.spi.SessionFactoryOptions#isUseOfJdbcNamedParametersEnabled()

When enabled, specifies that queries created via jakarta.persistence.EntityManager#createQuery(CriteriaQuery), jakarta.persistence.EntityManager#createQuery(CriteriaUpdate) or jakarta.persistence.EntityManager#createQuery(CriteriaDelete) must create a copy of the passed criteria query object such that the resulting jakarta.persistence.Query object is not affected by mutation of the original criteria query.

If disabled, it's assumed that the client does not mutate the criteria query after calling createQuery(). Thus, in the interest of performance, no copy is created.

The default behavior depends on how Hibernate is bootstrapped:

• When bootstrapping Hibernate through the native bootstrap APIs, this setting is disabled, that is, no copy of the criteria query object is made.
• When bootstrapping Hibernate through the JPA SPI, this setting is enabled so that criteria query objects are copied, as required by the JPA specification.

Since

6.0

By default, a criteria query produces SQL with a JDBC bind parameter for any value specified via the criteria query API, except when the value is passed via jakarta.persistence.criteria.CriteriaBuilder#literal(Object), in which case the value is "inlined" as a SQL literal.

This setting may be used to override this default behavior:

• the "bind" mode uses bind parameters to pass such values to JDBC, but
• the "inline" mode inlines values as SQL literals.

In both modes:

• values specified using literal() are inlined, and
• values specified using jakarta.persistence.criteria.CriteriaBuilder#parameter(Class) to create a criteria parameter and jakarta.persistence.Query#setParameter(jakarta.persistence.Parameter, Object) to specify its argument are passed to JDBC using a bind parameter.

The default mode is org.hibernate.query.criteria.ValueHandlingMode#BIND.

Since

6.0.0

See Also

org.hibernate.query.criteria.ValueHandlingMode, jakarta.persistence.criteria.CriteriaBuilder#literal(Object), jakarta.persistence.criteria.CriteriaBuilder#parameter(Class), org.hibernate.query.criteria.HibernateCriteriaBuilder#value(Object)

Specifies the default precedence of null values in the HQL ORDER BY clause, either none, first, or last.

The default is none.

See Also

NullPrecedence, org.hibernate.boot.SessionFactoryBuilder#applyDefaultNullPrecedence(NullPrecedence)

When pagination is used in combination with a fetch join applied to a collection or many-valued association, the limit must be applied in-memory instead of on the database. This typically has terrible performance characteristics, and should be avoided.

When enabled, this setting specifies that an exception should be thrown for any query which would result in the limit being applied in-memory.

By default, the exception is disabled, and the possibility of terrible performance is left as a problem for the client to avoid.

Since

5.2.13

This setting defines how org.hibernate.annotations.Immutable entities are handled when executing a bulk update query. Valid options are enumerated by org.hibernate.query.ImmutableEntityUpdateQueryHandlingMode:

• "warning" specifies that a warning log message is issued when an immutable entity is to be updated via a bulk update statement, and
• "exception" specifies that a org.hibernate.HibernateException should be thrown.

By default, a warning is logged.

Since

5.2.17

See Also

org.hibernate.query.ImmutableEntityUpdateQueryHandlingMode

Determines how parameters occurring in a SQL IN predicate are expanded. By default, the IN predicate expands to include sufficient bind parameters to accommodate the specified arguments.

However, for database systems supporting execution plan caching, there's a better chance of hitting the cache if the number of possible IN clause parameter list lengths is smaller.

When this setting is enabled, we expand the number of bind parameters to an integer power of two: 4, 8, 16, 32, 64. Thus, if 5, 6, or 7 arguments are bound to a parameter, a SQL statement with 8 bind parameters in the IN clause will be used, and null will be bound to the left-over parameters.

Since

5.2.17

When set to true, indicates that ordinal parameters (represented by the '?' placeholder) in native queries will be ignored.

By default, this is set to false, i.e. native queries will be checked for ordinal placeholders.

See Also

SessionFactoryOptions#getIgnoreNativeJdbcParameters()

Defines the "global" strategy to use for handling HQL and Criteria insert queries. Specifies a org.hibernate.query.sqm.mutation.spi.SqmMultiTableInsertStrategy.

Defines the "global" strategy to use for handling HQL and Criteria mutation queries. Specifies a org.hibernate.query.sqm.mutation.spi.SqmMultiTableMutationStrategy..

When enabled, specifies that query plans should be cached.

By default, the query plan cache is disabled, unless one of the configuration properties hibernate.query.plan_cache_max_size or hibernate.query.plan_parameter_metadata_max_size is set.

The maximum number of entries in the query interpretation cache.

The default maximum is 2048.

See Also

org.hibernate.query.spi.QueryInterpretationCache

The maximum number of org.hibernate.query.ParameterMetadata instances maintained by the org.hibernate.query.spi.QueryInterpretationCache.

When enabled, specifies that named queries be checked during startup.

By default, named queries are checked at startup.

Mainly intended for use in test environments.

See Also

org.hibernate.boot.SessionFactoryBuilder#applyNamedQueryCheckingOnStartup(boolean)

Specifies a org.hibernate.query.hql.HqlTranslator to use for HQL query translation.

Specifies a org.hibernate.query.sqm.sql.SqmTranslatorFactory to use for HQL query translation.