Package org.hibernate.jpa.spi

Interface JpaCompliance

All Known Subinterfaces:

MutableJpaCompliance

All Known Implementing Classes:

JpaComplianceImpl, MutableJpaComplianceImpl

public interface JpaCompliance

Encapsulates settings controlling whether Hibernate complies strictly with certain debatable strictures of the JPA specification.

Author:

Steve Ebersole

Method Summary

Modifier and Type	Method	Description
boolean	isGlobalGeneratorScopeEnabled()	Should the scope of TableGenerator.name() and SequenceGenerator.name() be considered globally or locally defined?
boolean	isJpaCacheComplianceEnabled()	Should Hibernate comply with all aspects of caching as defined by JPA?
boolean	isJpaCascadeComplianceEnabled()	JPA specifies that a CascadeType.PERSIST operation should occur at flush time.
boolean	isJpaClosedComplianceEnabled()	JPA defines specific exceptions on specific methods when called on EntityManager and EntityManagerFactory when those objects have been closed.
boolean	isJpaListComplianceEnabled()	Deprecated. Use MappingSettings.DEFAULT_LIST_SEMANTICS instead
boolean	isJpaOrderByMappingComplianceEnabled()	Should we strictly handle OrderBy expressions?
boolean	isJpaProxyComplianceEnabled()	JPA spec says that an EntityNotFoundException should be thrown when accessing an entity proxy which does not have an associated table row in the database.
boolean	isJpaQueryComplianceEnabled()	Controls whether Hibernate's handling of JPA's Query (JPQL, Criteria and native-query) should strictly follow the JPA spec.
boolean	isJpaTransactionComplianceEnabled()	Indicates that Hibernate's Transaction should behave as defined by the specification for JPA's EntityTransaction since it extends it.
boolean	isLoadByIdComplianceEnabled()	JPA says that the id passed to EntityManager.getReference(java.lang.Class<T>, java.lang.Object) and EntityManager.find(java.lang.Class<T>, java.lang.Object) should be exactly the expected type, allowing no type coercion.

Method Details

isJpaQueryComplianceEnabled

boolean isJpaQueryComplianceEnabled()

Controls whether Hibernate's handling of JPA's Query (JPQL, Criteria and native-query) should strictly follow the JPA spec. This includes parsing and translating a query as JPQL instead of HQL, as well as whether calls to the Query methods always throw the exceptions defined by the specification.

Deviations result in an exception, if enabled.

Returns:

true indicates to behave in the spec-defined way

See Also:

• JpaComplianceSettings.JPA_QUERY_COMPLIANCE

isJpaTransactionComplianceEnabled

boolean isJpaTransactionComplianceEnabled()

Indicates that Hibernate's Transaction should behave as defined by the specification for JPA's EntityTransaction since it extends it.

Returns:

true indicates to behave in the spec-defined way

See Also:

• JpaComplianceSettings.JPA_TRANSACTION_COMPLIANCE

isJpaListComplianceEnabled

@Deprecated(since="6.0")
boolean isJpaListComplianceEnabled()

Deprecated.

Use MappingSettings.DEFAULT_LIST_SEMANTICS instead

Controls how Hibernate interprets a mapped List without no order column specified. Historically Hibernate treats this as a "bag", which is a concept JPA does not have.

• If enabled, Hibernate will recognize this case as a list.
• Otherwise, if disabled, Hibernate will treat it as a "bag".

Returns:

true indicates to behave in the spec-defined way, interpreting the mapping as a "list", rather than a "bag"

See Also:

• JpaComplianceSettings.JPA_LIST_COMPLIANCE

isJpaClosedComplianceEnabled

boolean isJpaClosedComplianceEnabled()

JPA defines specific exceptions on specific methods when called on EntityManager and EntityManagerFactory when those objects have been closed. This setting controls whether the spec defined behavior or Hibernate's behavior will be used.

If enabled Hibernate will operate in the JPA specified way throwing exceptions when the spec says it should with regard to close checking

Returns:

true indicates to behave in the spec-defined way

See Also:

• JpaComplianceSettings.JPA_CLOSED_COMPLIANCE

isJpaCascadeComplianceEnabled

boolean isJpaCascadeComplianceEnabled()

JPA specifies that a CascadeType.PERSIST operation should occur at flush time. The legacy behavior of Hibernate was a CascadeType.SAVE_UPDATE.

Returns:

true indicates to behave in the spec-defined way

See Also:

• JpaComplianceSettings.JPA_CASCADE_COMPLIANCE

isJpaProxyComplianceEnabled

boolean isJpaProxyComplianceEnabled()

JPA spec says that an EntityNotFoundException should be thrown when accessing an entity proxy which does not have an associated table row in the database.

Traditionally, Hibernate does not initialize an entity Proxy when accessing its identifier since we already know the identifier value, hence we can save a database round trip.

If enabled Hibernate will initialize the entity proxy even when accessing its identifier.

Returns:

true indicates to behave in the spec-defined way

See Also:

• JpaComplianceSettings.JPA_PROXY_COMPLIANCE

isJpaCacheComplianceEnabled

boolean isJpaCacheComplianceEnabled()

Should Hibernate comply with all aspects of caching as defined by JPA? Or can it deviate to perform things it believes will be "better"?

Returns:

true indicates to behave in the spec-defined way

See Also:

• JpaComplianceSettings.JPA_CACHING_COMPLIANCE
• AbstractEntityPersister.isCacheInvalidationRequired()

isGlobalGeneratorScopeEnabled

boolean isGlobalGeneratorScopeEnabled()

Should the scope of TableGenerator.name() and SequenceGenerator.name() be considered globally or locally defined?

Returns:

true if the generator name scope is considered global

See Also:

• JpaComplianceSettings.JPA_ID_GENERATOR_GLOBAL_SCOPE_COMPLIANCE

isJpaOrderByMappingComplianceEnabled

boolean isJpaOrderByMappingComplianceEnabled()

Should we strictly handle OrderBy expressions?

JPA says the order-items can only be attribute references whereas Hibernate supports a wide range of items. With this enabled, Hibernate will throw a compliance error when a non-attribute-reference is used.

See Also:

• JpaComplianceSettings.JPA_ORDER_BY_MAPPING_COMPLIANCE

isLoadByIdComplianceEnabled

boolean isLoadByIdComplianceEnabled()

JPA says that the id passed to EntityManager.getReference(java.lang.Class<T>, java.lang.Object) and EntityManager.find(java.lang.Class<T>, java.lang.Object) should be exactly the expected type, allowing no type coercion.

Historically, Hibernate behaved the same way. Since 6.0 however, Hibernate has the ability to coerce the passed type to the expected type. For example, an Integer may be widened to Long. Coercion is performed by calling JavaType.coerce(X, org.hibernate.type.descriptor.java.JavaType.CoercionContext).

This setting controls whether such coercion should be allowed.

Since:

6.0

See Also:

• JpaComplianceSettings.JPA_LOAD_BY_ID_COMPLIANCE