Red Hat

In Relation To Steve Ebersole

In Relation To Steve Ebersole

ORM 5.1 feature release

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The Hibernate team is proud to announce the release of ORM 5.1 which includes a number of new features and enhancements, including:

Entity joins (or ad hoc joins)

In HQL you now have the ability to define a join to an entity, not just a mapped association. For example:

select ...
from FinancialRecord f
    left join User u
        on r.lastUpdateBy = u.username

See HHH-16 for details.

load-by-multiple-id API

Loading multiple entities of same type by identifier is now a first class API much like loading a single entity by identifier. For example:

// load Users 1, 2 and 3 at one shot
List<User> users = session.byMultipleIds(User.class)
    .multiLoad( 1, 2, 3 );

See HHH-7572 for details.

CDI integration improvements

Especially in regards to in-container integration, we have seen gaps between the JPA, CDI and EE specs in terms of timing between JPA and CDI components. Generally this manifests as Hibernate trying to access the CDI BeanManager too soon. 5.1 offers some solutions to deal with this. Long term we are working with the Weld development team to propose a solution at the JPA and CDI spec levels.

See HHH-8706 and HHH-10477 for details.

@Embeddables and all null column values

Historically Hibernate would always treat all null column values for an @Embeddable to mean that the @Embeddable should itself be null. 5.1 allows applications to dictate that Hibernate should instead use an empty @Embeddable instance. This is achieved via an opt-in setting: hibernate.create_empty_composites.enabled.

See HHH-7610 for details.

Envers audit queries can now refer to to-one associtions

When deinfing an Envers audit query you can now refer across an association.

A further performance improvement here will be for this feature to leverage the entity-join work (HHH-16) mentioned above. That work did not get done in time for inclusion in 5.1.0, but will be in 5.1.1.

See HHH-3555 for details.


In addition there have been many performance improvements and bug fixes.

There is a migration guide for migrating from 5.0→5.1. This is a temporary location; we hope to have a better option as part of http://hibernate.org longer term.

The complete list of changes can be found here (or here for people without a Hibernate Jira account).

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

7th bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The 7th bug-fix release for Hibernate ORM 5.0 has just been tagged and published.

The complete list of changes can be found here (or here for people without a Hibernate Jira account).

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

5th bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The 5th bug-fix release for Hibernate ORM 5.0 has just been tagged and published. This release and the upcoming 5.0.6 release have been done on an accelerated timebox of 2 weeks (from the normal 4 weeks for bugfix releases) due to US holidays.

The complete list of changes can be found here (or here for people without a Hibernate Jira account).

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

Fourth bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The fourth bug-fix release for Hibernate ORM 5.0 has just been tagged and published.

There are 52 issues resolved in this release. 20 of those came out of the recent Jira cleanup. Initially that initiative pulled in roughly 750 issues. To date, 66 of those have been resolved - fixed or verified as out-of-date, unable-to-reproduce, etc. An additional 14 have been more propoerly reclassified as feature or enhancement requests rather than bugs. The really cool part is the amount of community help we have gotten in making that happen! Thanks to everyone responding, verifying and even fixing alot of these bugs!

The complete list of changes can be found here. People without a Hibernate Jira account will not be able to access the previous link and can access the changelog in GitHub; the issue I reported with Atlassian has been resolved and is ready for deployment into our hosted environment, I just do not know when that will happen.

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

Third bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The third bug-fix release for Hibernate ORM 5.0 has just been published.

The complete list of changes can be found here. People without a Hibernate Jira account will not be able to access the previous link and can access the changelog in GitHub

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

The Great Jira Cleanup of 2015

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM

What is happening?

In an effort to focus attention on 5.0 and moving forward we will be bulk updating bug reports in Jira which are not indicated to affect 5.0 to request help for folks to verify that the reported issue still affects 5.0

Why is it happening?

Now that ORM 5.0 has gone final, we need to focus our development efforts on 5.0 and beyond. http://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team discusses why we do this. Put simply, versions prior to 5.x are no longer maintained and bug reports which do not affect 5.0 are outside that focus. We are asking your help to verify that the reported bug still affects version 5.0. This is a great help to the Hibernate team and to the Hibernate community.

We realize some of the issues caught up in this process may have already been caught up in the bulk clean up the last time we did it. We apologize, but the last time we did not do a great job setting up tracking for knowing when these issues were verified. This time we will be setting up filters so that we can see which issues are caught up in this process and which have been verified. We will tie those that have been verified into our weekly triage meeting amongst the development team and make sure that the verified issues get looked at.

How will it happen?

Essentially this will affect any issues which:

  • are a Bug report

  • are in the ORM (HHH) project

  • are Unresolved

  • have no fix-for version

  • do not list any 5.0 releases in affects version

This pool of issues is defined by a Jira filter: http://hibernate.atlassian.net/issues/?filter=16961

These issues will have a bulk update applied to them to:

  1. add the label verify-affects-5.0

  2. change status to Awaiting Response

  3. add a comment indicating that the issue has been included in this process, along with a link to this announcement

What needs done?

As discussed in http://github.com/hibernate/hibernate-orm/wiki/Jira-Report-Expectations, we are hoping for someone to champion these bug reports. But really, even verifying them is a great step towards getting them resolved.

http://hibernate.atlassian.net/issues/?filter=17060 defines the pool of bug reports waiting to be verified against 5.0. We are asking for help in verifying that these issues affect 5.0. That essentially means writing a test (or adapting an already attached test) to use 5.0 and verifying that the problem still exists. If it does still exist in 5.0, add the specific version used to test to the list of "Affects version/s" for the Jira issue and attach the test used to verify.

After a bug report is verified as affecting 5.0, the issue will move to the http://hibernate.atlassian.net/issues/?filter=17061. This pool of issues will then become part of the triage meeting the Hibernate ORM team has (roughly) once a week to be discussed and either scheduled, resolved or rejected.

Bug reports that sit in the "awaiting verification" pool will eventually be resolved as "Out of Date". Eventually is a fluid term; we have not defined any sort of timeline for when that would happen; but I expect it would be allowed to sit there for months before we get to that point.

Second bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The second bug-fix release for Hibernate ORM 5.0 has just been published.

The complete list of changes can be found here.

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

First bug-fix release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

The first bug-fix release for Hibernate ORM 5.0 has just been published. It is tagged at https://github.com/hibernate/hibernate-orm/releases/tag/5.0.1.Final

The complete list of changes can be found here.

For information on consuming the release via your favorite dependency-management-capable build tool, see http://hibernate.org/orm/downloads/

For those of you allergic to dependency-management-capable build tools, the release bundles can be obtained from SourceForge or BinTray.

Hibernate ORM 5.0 has gone Final!

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

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:

New bootstrap API

The venerable way to bootstrap Hibernate (build a SessionFactory) has been to use its Configuration class. Configuration, historically, allowed users to iteratively add settings and mappings in any order and to query the state of settings and mapping information in the middle of that process. Which meant that building the mapping information could not effectively rely on any settings being available. This lead to many limitations and problems.

5.0 introduces a new bootstrapping API aimed at alleviating those limitations and problems, while allowing better determinism and better integration. See the Bootstrap chapter in the User Guide for details on using the new API.

Configuration is still available for use, although in a limited sense. Some of its methods have been removed. Under the covers Configuration makes use of the new bootstrap API.

Spatial/GIS support

Hibernate Spatial is a project that has been around for a number of years. Karel Maesen has done an amazing job with it.

Starting in 5.0 Hibernate Spatial is now part of the Hibernate project proper to allow it to better keep up with upstream development. It is available as org.hibernate:hibernate-spatial. If your appplication has need for GIS data, we highly recommend giving hibernate-spatial a try.

Java 8 support

Well, ok.. not all of Java 8. Specifically we have added support for Java 8 Date and Time API in regards to easily mapping attributes in your domain model using the Java 8 Date and Time API types to the database. This support is available under the dedicated hibernate-java8 artifact (to isolate Java 8 dependencies). For additional information, see the Basic Types chapter in the Domain Model Mapping Guide.

Expanded AUTO id generation support

JPA defines support for GenerationType#AUTO limited to just Number types. Starting in 5.0 Hibernate offers expandable support for a broader set of types, including built-in support for both Number types (Integer, Long, etc) and UUID. Users are also free to plug in custom strategies for interpreting GenerationType#AUTO via the new org.hibernate.boot.model.IdGeneratorStrategyInterpreter extension.

Naming strategy split

NamingStrategy has been removed in favor of a better designed API. 2 distinct ones actually:

  • org.hibernate.boot.model.naming.ImplicitNamingStrategy - used whenever a table or column is not explicitly named to determine the name to use

  • org.hibernate.boot.model.naming.PhysicalNamingStrategy - used to convert a "logical name" (either implicit or explicit) name of a table or column into a physical name (e.g. following corporate naming guidelines)

Attribute Converter support

5.0 offers significantly improved support for JPA 2.1 AttributeConverters:

  • fully supported for non-@Enumerated enum values

  • applicable in conjunction with @Nationalized support

  • now called to handle null values

  • settable in hbm.xml by using type="converter:fully.qualified.AttributeConverterName"

  • integrated with hibernate-envers

  • collection values, map keys

  • support for conversion of parameterized types

Better "bulk id table" support

Support for "bulk id tables" has been completely redesigned to better fit what different databases support.

Transaction management

The transaction SPI underwent a major redesign as part of 5.0 as well. From a user perspective this generally only comes into view in terms of configuration. Previously applications would work with the different backend transaction stratagies directly via the org.hibernate.Transaction API. In 5.0 a level of indirection has been added here. The API implementation of org.hibernate.Transaction is always the same now. On the backend, the org.hibernate.Transaction impl talks to a org.hibernate.resource.transaction.TransactionCoordinator which represents the "transactional context" for a given Session according to the backend transaction strategy. Users generally do not need to care about the distinction.

The change is noted here because it might affect your bootstrap configuration. Whereas previously applications would specify hibernate.transaction.factory_class and refer to a org.hibernate.engine.transaction.spi.TransactionFactory FQN, with 5.0 the new contract is org.hibernate.resource.transaction.TransactionCoordinatorBuilder and is specified using the hibernate.transaction.coordinator_class setting. See org.hibernate.cfg.AvailableSettings.TRANSACTION_COORDINATOR_STRATEGY JavaDocs for additional details.

The following short-names are recognized: jdbc::(the default) says to use JDBC-based transactions (org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl) jta::says to use JTA-based transactions (org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl)

See the User Guide for additional details.

Schema Tooling

5.0 offers much improvement in the area of schema tooling (export, validation and migration).

Typed Session API

Hibernate’s native APIs (Session, etc) have been updated to be typed. No more casting!

Improved OSGi support

Really this started with a frustration over the fragility of hibernate-osgi tests. The first piece was a better testing setup using Pax Exam and Karaf. This lead to us generating (and now publishing!) a Hibernate Karaf features file.

OSGi support has undergone some general improvement as well thanks to feedback from some Karaf and Pax developers and users.

See the Getting Started Guide for additional details on using the new Karaf features file.

Improved bytecode enhancement capabilities

Work on documentation

A lot of work has gone into the documentation for 5.0. It’s still not complete (is documentation ever "complete"?), but it is much improved.

See the revamped documentation page for details.

BinTray

For now the plan is to publish the release bundles (zip and tgz) to BinTray. We will continue to publish to SourceForge as well. For the time being we will publish the bundles to both.

Ultimately we will start to publish the "maven" artifacts there as well.

This is all a work in progress.

How to get it

See http://hibernate.atlassian.net/projects/HHH/versions/20851 for the complete list of changes.

See http://hibernate.org/orm/downloads/ for information on obtaining the releases.

Fourth Candidate Release for ORM 5.0

Posted by Steve Ebersole    |       |    Tagged as Hibernate ORM Releases

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.

Default ImplicitNamingStrategy

The default ImplicitNamingStrategy (hibernate.implicit_naming_strategy) has changed to the JPA-compliant one. Additionally I added some short-names for the Hibernate-provided implementations.

  • "default" → org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl

  • "jpa" → org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl

  • "legacy-jpa" → org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl

  • "legacy-hbm" → org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl

  • "component-path" → org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl

The previous default was "legacy-jpa". Existing applications that previously used the default naming strategy and want to continue to use that implicit naming strategy should specify hibernate.implicit_naming_strategy=legacy-jpa in their configuration settings. Alternatively, they can call MetadataBuilder#setImplicitNamingStrategy(ImplicitNamingStrategyLegacyJpaImpl.INSTANCE).

Identifier generator mapping

Back in 3.6 I developed a new set of identifier generator strategies aimed at database portability based on the JPA expectations for @SequenceGenerator and @TableGenerator. Between 3.6 and now the default has been to continue to use the legacy generator strategies, but we added a setting (hibernate.id.new_generator_mappings) to allow applications to request the newer strategies be used. The default for this setting had been false. The default is now true.

Existing applications updating to CR4 and then Final that experience issues with identifier generator strategy selection should try setting this back to false if they wish to keep using the legacy mappings.

Keyword auto-quoting

This is a new feature in 5.0, but previously the default had been to auto-quote any sql identifiers believed to be a keyword in the underlying database. That feature has been disabled by default.

Applications that wish to use this feature should explicitly enable it by specifying hibernate.auto_quote_keyword=true in their configuration settings.

More work on the documentation

Still in progress, but alot more content has been added.

How to get it

Additionally many other improvements and bugfixes are included. See https://hibernate.atlassian.net/projects/HHH/versions/20752 for the complete list of changes.

As always, see http://hibernate.org/orm/downloads/ for information on obtaining the releases.

back to top