/hibernate-orm

Permalink
Switch branches/tags
5.3.7 5.3.6 5.3.5 5.3.4 5.3.3 5.3.2 5.3.1 5.3.0.Final 5.3.0.CR2 5.3.0.Beta2 5.3.0.Beta1 5.2.17 5.2.16 5.2.15 5.2.14 5.2.13 5.2.12 5.2.11 5.2.10 5.2.9 5.2.8 5.2.7 5.2.6 5.2.5 5.2.4 5.2.3 5.2.2 5.2.1 5.2.0 5.1.16 5.1.15 5.1.14 5.1.13 5.1.12 5.1.11 5.1.10 5.1.9 5.1.8 5.1.7 5.1.6 5.1.5 5.1.4 5.1.3 5.1.2 5.1.1 5.1.0 5.0.16 5.0.15 5.0.14 5.0.13 5.0.12 5.0.11 5.0.10 5.0.9 5.0.8 5.0.7 5.0.6 5.0.5 5.0.4 5.0.3 5.0.2.Final 5.0.1.Final 5.0.0.Final 5.0.0.CR4 5.0.0.CR3 5.0.0.CR2 5.0.0.CR1 5.0.0.Beta2 5.0.0.Beta1 4.3.11.Final 4.3.10.Final 4.3.9.Final 4.3.8.Final 4.3.7.Final 4.3.6.Final 4.3.5.Final 4.3.4.Final 4.3.3.Final 4.3.2.Final 4.3.1.Final 4.3.0.Final 4.3.0.CR2 4.3.0.CR1 4.3.0.Beta5 4.3.0.Beta4 4.3.0.Beta3 4.3.0.Beta2 4.3.0.Beta1 4.2.27.Final 4.2.26.Final 4.2.25.Final 4.2.24.Final 4.2.23.Final 4.2.22.Final 4.2.21.Final 4.2.20.Final 4.2.19.Final 4.2.18.Final 4.2.17.Final 4.2.16.Final
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
Raw Blame History
66 lines (44 sloc) 3.5 KB

5.1 Migration Guide

Table of Contents

This guide discusses migration from Hibernate ORM version 5.0 to version 5.1. For migration from earlier versions, see any other pertinent migration guides as well.

Oracle12cDialect maps byte[] and Byte[] to BLOB

Previous versions of Hibernate have mapped byte[] and Byte[] to Oracle’s LONG RAW data type (via the JDBC LONGVARBINARY type). Oracle have deprecated the LONG RAW data type for many releases - possibly as far back as 8i. Therefore it was decided to start having Hibernate map byte[] and Byte[] to BLOB for Oracle.

However, in the interest of backwards compatibility and not breaking existing applications it was also decided to limit this change to just the Oracle12cDialect. So starting in 5.1 applications using Oracle12cDialect and implicitly mapping byte[] and Byte[] values will start seeing those handled as BLOB data rather than LONG RAW data. For existing applications that want to continue to use Oracle12cDialect and still continue to implicitly map byte[] and Byte[] attributes to LONG RAW, there is a new configuration setting you can use to enable that: hibernate.dialect.oracle.prefer_longvarbinary, which is false by default (map to BLOB).

Changes to schema management tooling

The changes mainly focused on:

  • Unifying handling of hbm2ddl.auto and Hibernate’s JPA schema-generation support.

  • Removing JDBC concerns from the SPI to facilitate true replacement (for OGM)

These changes will only be a migration concern for applications directly using any of the following classes:

  • org.hibernate.tool.hbm2ddl.SchemaExport

  • org.hibernate.tool.hbm2ddl.SchemaUpdate

  • org.hibernate.tool.hbm2ddl.SchemaValidator

  • org.hibernate.tool.schema.spi.SchemaManagementTool or any of its delegates

In 5.1.4, a new strategy for retrieving database tables was introduced that improves SchemaMigrator and SchemaValidator performance. This strategy executes a single java.sql.DatabaseMetaData#getTables(String, String, String, String[]) call to determine if each javax.persistence.Entity has a mapped database table. This strategy is the default, and uses the property setting hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=grouped. This strategy may require hibernate.default_schema and/or hibernate.default_catalog to be provided.

To use the old strategy, which executes a java.sql.DatabaseMetaData#getTables(String, String, String, String[]) call for each javax.persistence.Entity, use the property setting hibernate.hbm2ddl.jdbc_metadata_extraction_strategy=individually.

Many-to-one association in embeddable collection elements and composite IDs

A bug introduced in 4.3 caused many-to-one associations in embeddable collection elements and composite IDs to be eagerly fetched, even when explicitly mapped as lazy.

This bug does not affect many-to-one associations that are not in a composite ID or embeddable collection element.

In 5.1.15, this bug was fixed. As a result, such associations will be fetched as specified by their mappings.

Many-to-one associations mapped by using native HBM xml are lazy by default. In order to keep the associations eager in 5.1.15 and later, mappings will need to explicitly specify that they are non-lazy.

When mapped with annotations, many-to-one associations use FetchType.EAGER by default. Starting in 5.1.15, if an association is mapped with FetchType.LAZY, the assocation will be lazily fetched, as expected.

See details on the HHH-12687 Jira issue.