Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

prep 6.5

This commit is contained in:
Steve Ebersole 2024-03-20 12:27:48 -05:00
parent 62d1f1a13a
commit 59de4f05f3
2 changed files with 207 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
migration-guide.adoc
View File

@ -40,16 +40,17 @@ hibernate.type.prefer_java_type_jdbc_types=true
It is expected the default will flip for 7.0.
[[query-cache-layout]]
== Query cache layout change
== Configurable Query Cache Layout
In Hibernate ORM 6.0 the query cache layout changed from a "shallow" representation of entities and collections,
to a "full" representation. This was done to enable to re-materialize join fetched data from just the query cache data.
Storing the full data in the query cache leads to a higher memory consumption,
to a "full" representation. This was done to support re-materializing join fetched data from the query cache data
without hitting the database. Storing the full data in the query cache leads to a higher memory consumption,
which in turn might also hurt application throughput due to a higher garbage collection activity.
Hibernate ORM 6.5 introduces means to configure the query cache layout globally via the `hibernate.cache.query_cache_layout`
property, and also for an entity type or persistent collection with the `@QueryCacheLayout` annotation.
6.5 adds the ability to configure the format in which query results are stored in the query cache, either
* globally via the `hibernate.cache.query_cache_layout` setting
* per entity or collection via the `@QueryCacheLayout` annotation
The global `hibernate.cache.query_cache_layout` setting defaults to the `AUTO` value,
which will automatically choose `SHALLOW` or `FULL` for an entity/collection,
@ -60,11 +61,16 @@ the global property `hibernate.cache.query_cache_layout=FULL`.
Applications that want the cache layout that Hibernate ORM 5 and older versions used should configure
the global property `hibernate.cache.query_cache_layout=SHALLOW`.
Note that even with the shallow cache layout, the association eagerness implied through join fetches will be respected,
and associations will be eagerly initialized, so there is no change of behavior when choosing a different cache layout.
[NOTE]
====
Even with the `SHALLOW` cache layout, the association eagerness implied through join fetches will be respected,
and associations will be eagerly initialized. So there is no change of behavior when choosing a different cache layout.
With `SHALLOW`, Hibernate might need to hit the database to materialize the associated data *if it does not exist in the second level cache*.
====
[[ddl-implicit-datatype-enum]]
== Datatype for enums
== Datatype for enums (H2)
Hibernate ORM 6.5 now uses the `ENUM` datatype for `@Enumerated(EnumType.STRING)` enumeration mappings by default on H2,
just like link:{docsBase}/6.2/migration-guide/migration-guide.html#ddl-implicit-datatype-enum[ORM 6.2 already started doing for MySQL/MariaDB].
@ -90,14 +96,40 @@ explicit settings for this configuration. At a minimum this includes:
* `jakarta.persistence.database-product-version` to indicate the database version
[[query-result-validation]]
== Validation of Query Result Type
6.5 does more stringent checks that the reported query result type (if one) matches the actual query return type.
This will show up as a `org.hibernate.TypeMismatchException`.
[[sql-expectation]]
== SQL Execution Expectation
6.5 moves away from an enumeration approach to specifying the expected outcome of specific SQL executions to
a more flexible approach of directly specifying the `Expectation` implementation to use.
a more extendable approach of directly specifying the `Expectation` implementation to use.
`ExecuteUpdateResultCheckStyle` and `ResultCheckStyle` approaches are still available, though deprecated.
The enumerated values are replaced by -
* `org.hibernate.jdbc.Expectation.None`
* `org.hibernate.jdbc.Expectation.RowCount`
* `org.hibernate.jdbc.Expectation.OutParameter`
To update, change e.g.
[source,java]
----
@SQLInsert(check=ResultCheckStyle.COUNT)
----
to
[source,java]
----
@SQLInsert(verify=Expectation.RowCount.class)
----
[[uk-naming]]
== Unique Key Naming

165
release-announcement.adoc Normal file
View File

@ -0,0 +1,165 @@
= Hibernate 6.5.0.CR1
Steve Ebersole
:awestruct-tags: ["Hibernate ORM", "Releases"]
:awestruct-layout: blog-post
:family: 6.5
:docs-url: https://docs.jboss.org/hibernate/orm/{family}
:javadocs-url: {docs-url}/javadocs
:migration-guide-url: {docs-url}/migration-guide/migration-guide.html
:intro-guide-url: {docs-url}/introduction/html_single/Hibernate_Introduction.html
:user-guide-url: {docs-url}/userguide/html_single/Hibernate_User_Guide.html
:ql-guide-url: {docs-url}/querylanguage/html_single/Hibernate_Query_Language.html
6.5 brings many new features, in addition to many improvements and fixes.
[[java-time]]
== Java Time Handling
Java Time objects can now be directly marshalled through the JDBC driver as defined by JDBC 4.2.
In previous versions, Hibernate would handle Java Time objects using `java.sql.Date`, `java.sql.Time` or
`java.sql.Timestamp` references as intermediate forms.
Another behavioral change with this is handling for timezones. `OffsetDateTime`, `OffsetTime` and
`ZonedDateTime` all encode explicit timezone information. With direct marshalling, Hibernate simply
passes along the value as-is. In the legacy behavior, since the `java.sql` variants do not
encode timezone information, Hibernate generally has to specially handle timezones when converting to
those intermediate forms.
For 6.5 this behavior is disabled by default. To opt-in,
[source,properties]
----
hibernate.type.prefer_java_type_jdbc_types=true
----
See the link:{javadocs-url}/org/hibernate/cfg/MappingSettings.html#PREFER_JAVA_TYPE_JDBC_TYPES[setting Javadoc] for additional details.
[[query-cache-layout]]
== Configurable Query Cache Layout
In Hibernate ORM 6.0 the query cache layout changed from a "shallow" representation of entities and collections,
to a "full" representation. This was done to support re-materializing join fetched data from the query cache data
without hitting the database. Storing the full data in the query cache leads to a higher memory consumption,
which in turn might also hurt application throughput due to a higher garbage collection activity.
6.5 adds the ability to configure the format in which query results are stored in the query cache, either
* globally via the `hibernate.cache.query_cache_layout` setting
* per entity or collection via the `@QueryCacheLayout` annotation
The global `hibernate.cache.query_cache_layout` setting defaults to the `AUTO` value,
which will automatically choose `SHALLOW` or `FULL` for an entity/collection,
depending on whether the entity/collection is cacheable.
Applications that want to retain the `FULL` cache layout that Hibernate ORM 6.0 used should configure
the global property `hibernate.cache.query_cache_layout=FULL`.
Applications that want the cache layout that Hibernate ORM 5 and older versions used should configure
the global property `hibernate.cache.query_cache_layout=SHALLOW`.
[NOTE]
====
Even with the `SHALLOW` cache layout, the association eagerness implied through join fetches will be respected,
and associations will be eagerly initialized. So there is no change of behavior when choosing a different cache layout.
With `SHALLOW`, Hibernate might need to hit the database to materialize the associated data *if it does not exist in the second level cache*.
====
[[record-as-idclass]]
== Allow Java record as @IdClass
A Java record can now be used as an `@IdClass`
[source,java]
----
record PK(Integer key1, Integer key2) {}
@Entity
@IdClass(PK.class)
class AnEntity {
@Id Integer key1;
@Id Integer key2;
...
}
----
[[sqm-mutation-joins]]
== Joined Mutation Queries
UPDATE and DELETE queries can now use joins, e.g.
[source]
----
delete from Person p where p.association.someAttr = 1
----
[[manually-assigned-generated-ids]]
== Manually Assigned Identifiers with @GeneratedValue
Manually assigned identifier values can now be used with `GeneratedValue` identifiers.
[source,java]
----
@Entity
class Book {
@Id @GeneratedValue
Integer id;
...
}
Book book = new Book(1,...)
session.persist(book);
----
[[query-result-count]]
== SelectionQuery.getResultCount()
Selection queries now have the ability to report the number of results there will
be in the final result.
IMPORTANT: This triggers a query against the database.
[source,java]
----
Query query = session.createQuery("from Person");
int results = query.getResultCount();
----
[[key-pagination]]
== Key-based Pagination
[[on-conflict]]
== ON CONFLICT Clause for Insert Queries
Both HQL and Criteria now support an optional ON CONFLICT clause to allow controlling what
should happen when a constraint violation occurs, e.g.
[source]
----
insert into Person (id, name)
values (1, 'John')
on conflict do nothing
----
See the link:{user-guide-url}#hql-insert[User Guide] for more details.
[[stateless-session]]
== Work on StatelessSession
`StatelessSession` now supports https://hibernate.atlassian.net/browse/HHH-17620[filters] and https://hibernate.atlassian.net/browse/HHH-17673[SQL logging]
[[jakarta-data]]
== Jakarta Data
6.5 also includes a tech preview of Jakarta Data based on the Hibernate annotation processor.