Tags
Authors
The fourth beta release of Hibernate 7 is now available.
Along with many bugfixes and minor improvements, this release features the following enhancements:
-
The brand-new
Restriction
,Path
, andRange
APIs make it easy to add programmatic restrictions to HQL queries or Jakarta Data repository methods in a completely type-safe way. -
The package
org.hibernate.graph
was completely re-engineered, fixing a number of long-standing issues with our implementation of the Jakarta PersistenceEntityGraph
API. -
StatelessSession
is now able to make use of the second-level cache, reflecting the changing role of this very important API in the Hibernate ecosystem. -
Reactive repositories backed by Hibernate Reactive are now a documented feature of Hibernate Data Repositories.
-
The
hibernate-jfr
module was enhanced to send more events to Java Flight Recorder. -
HQL now provides portable
sha()
,md5()
, andhex()
functions. -
Hibernate Processor now features much better support for inner classes.
Last week, Jeroen Borgers asked on Twitter for a standard way to set the JDBC fetch size in JPA, that is, for Hibernate’s Query.setFetchSize()
to be added to the standard APIs.
This took me slightly by surprise, because nobody has ever asked for that before, but I asked him to go ahead and open an issue.
After some discussion, I think I’m satisfied that his actual needs can be met in a different way, but the discussion did help to draw my attention to something important: the default JDBC fetch size for the Oracle driver is 10.
Now, I would never pretend to be an expert in Oracle performance tuning, and I don’t use Oracle every day. Even so, I felt like this is something that I definitely should have known off the top of my head, after so many years working with JDBC.
Out of curiosity, I ran a poll on Twitter, which was shared by Franck Pachot among others:
Release Announcements
As we have continued automating much of our processes, one item that has become increasing more scripted is releases. That automation creates a GitHub release for each release we do.
GitHub exposes an RSS feed for a project’s releases. For Hibernate ORM, that URL is https://github.com/hibernate/hibernate-orm/releases.atom [1].
There are many excellent ways to be notified of releases through this RSS feed, including many email clients. And many people already consume these release announcements using RSS from this site.
A few weeks ago, the GitHub Security Lab reported to the Hibernate team a vulnerability in GitHub Actions workflows used in some Hibernate projects, which could have (indirectly) impacted released artifacts.
Fortunately, that vulnerability wasn’t exploited and all Hibernate releases are perfectly safe.
However, considering the impact an exploit could have had, we thought it would be best to provide some transparency on what happened and how we made sure that Hibernate releases — past, present and future — are safe.
I think it’s fair to say that Jakarta Persistence has too many options for mapping collections and to-many associations. Way back when we wrote JPA 1.0, I argued against adding so many things, on the grounds that a lot of these options tend to lead users down the wrong path. But the things I wasn’t keen on were ultimately added in JPA 2.0, and I can’t really say this was a bad decision, since all these options are things users ask for.
That said, I’m going to begin by reiterating what I’ve said many times before:
[ ... ]
Today someone asked us to add some documentation explaining how to deal with addition of elements to very large collections. I’m not sure if this is a topic I really want to talk about in the documentation, but it’s definitely worth a blog.