Today I have released Hibernate ORM 5.0 (5.0.0.Final). This has been a long time coming and is the result
of the efforts of many folks. Thanks to everyone who helped us get here with fixes, bug reports, suggestions,
input and encouragement!
A lot of development has gone into 5.0. Here are the big points:
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:
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.