In Relation To

Hibernate ORM 4.2.20.Final was released 24-July-2015. At the time it was released, SourceForge was out of commission so distributions could not be uploaded. I decided to delay the announcement until SourceForge was back in commission and I was able to release 4.3.11.Final on 5-Aug-2015.

Today I released a fourth candidate release for Hibernate ORM 5.0 (5.0.0.CR4). The purpose was entirely to change the defaults for some settings. This allowed some additional fixes and additional documentation work to make it in.

Yesterday I released the third candidate release for Hibernate ORM 5.0 (5.0.0.CR3). We felt another CR was warranted because we had some minor integration (SPI) work that we needed to make in to Final, but too much development had happened since the second CR to be considered risk free to just include everything into Final. At any rate CR3 got lots of great TLC :) The complete set of changes can be seen in the Jira changelog. The main changes include:

The other day I came across an interesting mapping challenge which I thought may be worth sharing. If you are a seasoned JPA user, it will probably be nothing new to you, but those not as experienced may find it helpful :)

TL;DR - JPA let’s you override database columns for embedded objects but also for collections of embedded objects; @AttributeOverride and @AssocationOverride can be used for that.

Let’s assume the following entity model representing a person and their home and business address:

Hibernate ORM, IntelliJ IDEA and Mac OS X have been a pretty tough combination to work with since our move to Gradle. It’s not exactly anyone’s fault but the combination of

made for a long and painful journey.

These days are over. Steve found the last blocking issue and you can now import Hibernate ORM natively in IntelliJ IDEA.

The second candidate release for Hibernate ORM 5.0. CR2 was required because of a bug in how class-loading worked in certain managed JPA environments. The details can be found in HHH-9887. The main changes since CR1 include:

Today let’s discuss the interaction between multitenancy and the current session feature.

Multitenancy let’s you isolate Session operations between different tenants. This is useful to create a single application isolating different customers from one another.

The current session feature returns the same session for a given context, typically a (JTA) transaction. This facilitates the one session per view/transaction/conversation pattern and avoids the one session per operation anti-pattern.

When creating a bug report for any project within the Hibernate family, it’s extremely helpful (and, frankly, required) to have an adequate test case available. This is obviously important to make reproducing the issue as easy as possible. But it’s also vital longer-term. Nearly every bug fix should include a regression test, which is frequently based on the original reproducer (sometimes, it’s the reproducer, verbatim).

To help create useful test cases, we’re opening up a repo with various templates. Please see the READMEs in each project’s subdir for more info: Hibernate Test Case Templates

As a starting point, the repo contains two templates for ORM: