Hibernate ORM - hibernate-core 6.4.4.Final · org.hibernate.jpa.spi.JpaCompliance

Method Summary

Modifier and Type	Method and Description
public boolean	Returns: `true` if the generator name scope is considered global isGlobalGeneratorScopeEnabled() Should the scope of `jakarta.persistence.TableGenerator#name()` and `jakarta.persistence.SequenceGenerator#name()` be considered globally or locally defined?
public boolean	Returns: `true` indicates to behave in the spec-defined way isJpaCacheComplianceEnabled() Should Hibernate comply with all aspects of caching as defined by JPA?
public boolean	Returns: `true` indicates to behave in the spec-defined way isJpaClosedComplianceEnabled() JPA defines specific exceptions on specific methods when called on `jakarta.persistence.EntityManager` and `jakarta.persistence.EntityManagerFactory` when those objects have been closed.
public boolean	Returns: `true` indicates to behave in the spec-defined way, interpreting the mapping as a "list", rather than a "bag" isJpaListComplianceEnabled() Deprecated since 6.0. Use `org.hibernate.cfg.AvailableSettings#DEFAULT_LIST_SEMANTICS` instead Controls how Hibernate interprets a mapped `java.util.List` without no order column specified.
public boolean	isJpaOrderByMappingComplianceEnabled() Should we strictly handle `jakarta.persistence.OrderBy` expressions?
public boolean	Returns: `true` indicates to behave in the spec-defined way isJpaProxyComplianceEnabled() JPA spec says that an `jakarta.persistence.EntityNotFoundException` should be thrown when accessing an entity proxy which does not have an associated table row in the database.
public boolean	Returns: `true` indicates to behave in the spec-defined way isJpaQueryComplianceEnabled() Controls whether Hibernate's handling of JPA's `jakarta.persistence.Query` (JPQL, Criteria and native-query) should strictly follow the JPA spec.
public boolean	Returns: `true` indicates to behave in the spec-defined way isJpaTransactionComplianceEnabled() Indicates that Hibernate's `Transaction` should behave as defined by the specification for JPA's `jakarta.persistence.EntityTransaction` since it extends it.
public boolean	isLoadByIdComplianceEnabled() JPA says that the id passed to `jakarta.persistence.EntityManager#getReference` and `jakarta.persistence.EntityManager#find` should be exactly the expected type, allowing no type coercion.

Method Detail

isGlobalGeneratorScopeEnabled back to summary

isGlobalGeneratorScopeEnabled	back to summary
public boolean isGlobalGeneratorScopeEnabled() Should the scope of `jakarta.persistence.TableGenerator#name()` and `jakarta.persistence.SequenceGenerator#name()` be considered globally or locally defined? Returns:boolean `true` if the generator name scope is considered global See Also `org.hibernate.cfg.AvailableSettings#JPA_ID_GENERATOR_GLOBAL_SCOPE_COMPLIANCE`

public boolean isGlobalGeneratorScopeEnabled()

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

Returns:boolean: true if the generator name scope is considered global
See Also: org.hibernate.cfg.AvailableSettings#JPA_ID_GENERATOR_GLOBAL_SCOPE_COMPLIANCE

isJpaCacheComplianceEnabled back to summary

isJpaCacheComplianceEnabled	back to summary
public 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"? Implementation Note Effects include marking all secondary tables as non-optional. The reason being that optional secondary tables can lead to entity cache being invalidated rather than updated. Returns:boolean `true` indicates to behave in the spec-defined way See Also `org.hibernate.cfg.AvailableSettings#JPA_CACHING_COMPLIANCE`, `org.hibernate.persister.entity.AbstractEntityPersister#isCacheInvalidationRequired()`

public 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"?

Implementation Note

Effects include marking all secondary tables as non-optional. The reason being that optional secondary tables can lead to entity cache being invalidated rather than updated.

Returns:boolean: true indicates to behave in the spec-defined way
See Also: org.hibernate.cfg.AvailableSettings#JPA_CACHING_COMPLIANCE, org.hibernate.persister.entity.AbstractEntityPersister#isCacheInvalidationRequired()

isJpaClosedComplianceEnabled back to summary

isJpaClosedComplianceEnabled	back to summary
public boolean isJpaClosedComplianceEnabled() JPA defines specific exceptions on specific methods when called on `jakarta.persistence.EntityManager` and `jakarta.persistence.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:boolean `true` indicates to behave in the spec-defined way See Also `org.hibernate.cfg.AvailableSettings#JPA_CLOSED_COMPLIANCE`

public boolean isJpaClosedComplianceEnabled()

JPA defines specific exceptions on specific methods when called on jakarta.persistence.EntityManager and jakarta.persistence.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:boolean: true indicates to behave in the spec-defined way
See Also: org.hibernate.cfg.AvailableSettings#JPA_CLOSED_COMPLIANCE

isJpaListComplianceEnabled back to summary

isJpaListComplianceEnabled	back to summary
public boolean isJpaListComplianceEnabled() Deprecated since 6.0. Use `org.hibernate.cfg.AvailableSettings#DEFAULT_LIST_SEMANTICS` instead Controls how Hibernate interprets a mapped `java.util.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:boolean `true` indicates to behave in the spec-defined way, interpreting the mapping as a "list", rather than a "bag" Annotations @Deprecated since:6.0 See Also `org.hibernate.cfg.AvailableSettings#JPA_LIST_COMPLIANCE`

public boolean isJpaListComplianceEnabled()

Deprecated

since 6.0.

Use org.hibernate.cfg.AvailableSettings#DEFAULT_LIST_SEMANTICS instead

Controls how Hibernate interprets a mapped java.util.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:boolean

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

Annotations

@Deprecated
since:6.0

isJpaOrderByMappingComplianceEnabled back to summary

isJpaOrderByMappingComplianceEnabled	back to summary
public boolean isJpaOrderByMappingComplianceEnabled() Should we strictly handle `jakarta.persistence.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 `org.hibernate.cfg.AvailableSettings#JPA_ORDER_BY_MAPPING_COMPLIANCE`

public boolean isJpaOrderByMappingComplianceEnabled()

Should we strictly handle jakarta.persistence.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: org.hibernate.cfg.AvailableSettings#JPA_ORDER_BY_MAPPING_COMPLIANCE

isJpaProxyComplianceEnabled back to summary

isJpaProxyComplianceEnabled	back to summary
public boolean isJpaProxyComplianceEnabled() JPA spec says that an `jakarta.persistence.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:boolean `true` indicates to behave in the spec-defined way See Also `org.hibernate.cfg.AvailableSettings#JPA_PROXY_COMPLIANCE`

public boolean isJpaProxyComplianceEnabled()

JPA spec says that an jakarta.persistence.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:boolean: true indicates to behave in the spec-defined way
See Also: org.hibernate.cfg.AvailableSettings#JPA_PROXY_COMPLIANCE

isJpaQueryComplianceEnabled back to summary

isJpaQueryComplianceEnabled	back to summary
public boolean isJpaQueryComplianceEnabled() Controls whether Hibernate's handling of JPA's `jakarta.persistence.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 `jakarta.persistence.Query` methods always throw the exceptions defined by the specification. Deviations result in an exception, if enabled. Returns:boolean `true` indicates to behave in the spec-defined way See Also `org.hibernate.cfg.AvailableSettings#JPA_QUERY_COMPLIANCE`

public boolean isJpaQueryComplianceEnabled()

Controls whether Hibernate's handling of JPA's jakarta.persistence.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 jakarta.persistence.Query methods always throw the exceptions defined by the specification.

Deviations result in an exception, if enabled.

Returns:boolean: true indicates to behave in the spec-defined way
See Also: org.hibernate.cfg.AvailableSettings#JPA_QUERY_COMPLIANCE

isJpaTransactionComplianceEnabled back to summary

isJpaTransactionComplianceEnabled	back to summary
public boolean isJpaTransactionComplianceEnabled() Indicates that Hibernate's `Transaction` should behave as defined by the specification for JPA's `jakarta.persistence.EntityTransaction` since it extends it. Returns:boolean `true` indicates to behave in the spec-defined way See Also `org.hibernate.cfg.AvailableSettings#JPA_TRANSACTION_COMPLIANCE`

public boolean isJpaTransactionComplianceEnabled()

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

Returns:boolean: true indicates to behave in the spec-defined way
See Also: org.hibernate.cfg.AvailableSettings#JPA_TRANSACTION_COMPLIANCE

isLoadByIdComplianceEnabled back to summary

isLoadByIdComplianceEnabled	back to summary
public boolean isLoadByIdComplianceEnabled() JPA says that the id passed to `jakarta.persistence.EntityManager#getReference` and `jakarta.persistence.EntityManager#find` 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 `org.hibernate.type.descriptor.java.JavaType#coerce`. This setting controls whether such coercion should be allowed. Since 6.0 See Also `org.hibernate.cfg.AvailableSettings#JPA_LOAD_BY_ID_COMPLIANCE`

public boolean isLoadByIdComplianceEnabled()

JPA says that the id passed to jakarta.persistence.EntityManager#getReference and jakarta.persistence.EntityManager#find 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 org.hibernate.type.descriptor.java.JavaType#coerce.

This setting controls whether such coercion should be allowed.

Since: 6.0
See Also: org.hibernate.cfg.AvailableSettings#JPA_LOAD_BY_ID_COMPLIANCE

public Interface JpaCompliance

Method Summary

Method Detail