In Relation To

Back to home

Hibernate ORM 6.2.6.Final released

Posted by    |       Hibernate ORM Releases

Today, we published a new maintenance release of Hibernate ORM 6.2: 6.2.6.Final.

What’s new

This update includes several bugfixes and further stabilization as we approach the release of the next minor Hibernate version.

Bugfixes

Embeddable keys and property sorting

We have fixed a bug that caused the properties of composite keys to be in an unexpected order, causing possible problems with constraints (see HHH-16514)

Bytecode enhancement

We keep improving Hibernate’s bytecode enhancement support, this time we tackled several bugs:

  • Reading entities that extended a @MappedSuperclass declared in a different package did not work correctly (see HHH-16711)

  • Bytecode enhancement caused a lazy @ManyToOne association targeting an Entity annotated with @Proxy(lazy = false) to be eagerly loaded (see HHH-16794)

  • Hibernate failed to update a one-to-one lazy association with OptimisticLockType.DIRTY and enabled bytecode enhancement (see HHH-16839)

  • Bytecode enhancement led to a broken constructor for an embedded field declared as a generic in a @MappedSuperclass (see HHH-16832)

Subqueries and joins

We addressed a couple issues that affected Hibernate generated subqeries when using joins:

  • When reusing a join in a subquery the table would be referenced again instead of reusing the join (see HHH-16537)

  • An HQL query with a subquery that used an entity path at least two levels deep produced SQL with a missing join predicate (see HHH-16721)

Polymorphic queries

We have fixed some bugs related to polymorphic queries:

  • When using a polymorphic entity-valued path as an argument for a function a SqmRoot not yet resolved to TableGroup error was triggered (see HHH-16733)

  • An exception was thrown when processing a polymorphic entity’s nested join in a subquery (see HHH-16582)

Hibernate now uses the existing SQM copy logic to process entity polymorphism, keeping the behavior consistent with what was already in place for criteria queries.

Batch loading

In previous 6.2 versions the batch loading feature was improved several times. With this release we keep stabilizing it by fixing a couple issues:

  • In-clause parameter padding did not consider the Dialect’s in-expression count limit which could cause errors on the DMBS side (see HHH-16589)

  • When batching was enabled the LockModeType requested through the session.find() method was ignored (see HHH-16820)

There are more improvements and bugfixes included in this version. You can find the full list of changes here.

Conclusion

For additional details, see:

Feedback, issues, ideas?

To get in touch, use the usual channels:

Back to top