Inactive Bloggers

Sometimes life is full of surprises. And I can say I was quite surprised when I learned that Hibernate OGM has been nominated for this year's Duke's Choice Award.

Being nominated is a great honor for us, so kudos to those who brought this on its way! But winning the award would be even better; so go to and vote for Hibernate OGM (upper right corner on the landing page). Every vote counts, and if you ever wanted to give back to Hibernate, this is your chance!

Hibernate OGM - What is it about and why should you vote for it?

In a word, Hibernate OGM (Object/Grid Mapper) gives you peace of mind when you need to persist Java domain models in NoSQL stores such as MongoDB, Infinispan or Neo4j. Based on the well-known semantics of JPA and re-using many parts of the proven Hibernate ORM engine, it provides simple access to this new world known as NoSQL.

For example consider an existing RDBMS-based application for address management which should be enhanced with some sort of friendship graph. Now handling and querying graph-like data is not exactly the specialty of RDBMS/SQL. Dedicated graph databases such as Neo4j are much better at this. With the help of Hibernate OGM, you could implement the friendship graph feature using the same persistence API you work with in the rest of the application. But for queries, you’d have the option to resort to powerful native queries written in Neo4j's Cypher language.

Hibernate OGM's vision is to enable applications to leverage those datastores being most beneficial for different use cases. Need deeply-nested hierarchical data? Use MongoDB. Need to distribute your data to hundreds of nodes with awesome performance? Use Infinispan. Need to work with graph-like data structures... You get the picture. But rather than using datastore-specific object mappers or even falling back to a store's native low-level API, you enjoy the comfort and power provided by the Hibernate engine.

Really, ORM for NoSQL?!

Now when we talk about this vision, we often get a glance from people which seems to ask But is JPA/ORM really a good fit for NoSQL?. To be honest, we were asking ourselves the same when starting the project. But over time it became apparent that the general idea of OxM (where x may stand for document, graph etc.) is not limited to relational datastores.

Most of JPA’s logical concepts - how do you define entities, their associations and so on - map excellently to NoSQL stores, sometimes arguably even better than to a RDMBS. Just to give an example, @ElementCollection is perfect for mapping nested dependent data in document stores such as MongoDB, which then can be accessed with a simple get, not requiring any joins; you don’t need to think about fetching strategies, orphan removal and the like.

Hibernate OGM benefits from many features of the Hibernate framework and the eco-system which has evolved around it. Any solution working with Hibernate will work with Hibernate OGM as well without further ado.

You need to validate your data but your store does not support check constraints or similar? No problem, just add Bean Validation constraints to your model and have them automatically validated when persisting your data. Your datastore doesn't provide sufficient query capabilities? Let Hibernate Search help you. It transparently indexes your data via Apache Lucene and allows to execute queries returning managed entities. If you like, even via JP-QL which is transformed into corresponding Lucene queries on the fly.

Of course you choose a certain store because of its specific capabilities, and not all of those may be exposed by a high-level abstraction such as JPA. Hibernate OGM gets out of your way as far as possible and for example allows you to specify queries in the store's native syntax (such as Cypher in the case of Neo4j). Also it's possible to apply store-specific options in a consistent and comfortable manner, via annotations or programmatically. For instance you can configure MongoDB's write concern and read preference settings individually for each of your mapped entities.

So is Hibernate OGM the perfect solution for all the possible challenges you may have when dealing with NoSQL?

Of course. NOT.

It will be very useful when dealing with well-defined domain models which need to be persisted, but as always there are situations in which an OxM tool may not be the best choice.

What's next?

The Hibernate OGM project has come a long way since its beginnings.

All the basics are in place, and at the moment we're fine-tuning some last details for the next release. It will be recommended for general usage and is to be expected soon. We're fixing some remaining glitches in the supported grid dialects and are validating that all the SPI contracts (which you may implement to add support for your favorite NoSQL store) are complete and correct. We’re also have a look on the performance side of things.

In future versions you may expect many more useful functionality such as support for true polyglot persistence (one domain model being spread across several data stores), implicit data migrations upon data load (for schema-less datastores) and declarative de-normalization of your data (ensuring fast retrieval in different use cases).

You like all this? Then don't forget to give your vote for the Duke's Choice Award on to Hibernate OGM. And please spread the word about the project and ask your friends to vote for it, too! If you want to learn more, take a look at our reference documentation. Or check out a complete sample application which has been built for a session at Red Hat Summit earlier this year.

Last week Emmanuel met up with Steven Hawkings and Ramesh Reddy in St. Louis and did a live interview.

They get to put on record the possible correct pronunciation of Teiid and to talk about how Teiid allows you to query across multiple datasources and provide a unified view on data in many different ways.

Show notes and episode

Have fun!

While the team is busy on significant internal refactoring, we also accumulated 30 minor fixes and improvements which have been merged in the master branch for Hibernate Search 5.

Since it was a while since the last published tag, today we're publishing this 5.0.0.Alpha5 release to make all these minor improvements available already, while the cooler features will need some more work.

New attribute: includeEmbeddedObjectId

This new attribute of the IndexedEmbedded annotation allows you to control if you want to store all ids for related objects which are embedded in the parent's Lucene Document. Very useful to save space in your index, and so improve performance, when you don't need these identifiers.

Other changes

  • As documented in the Migration guide the API to implement a JMS master node was simplified (but changed!).
  • A possible loss of index update events was fixed, but not a critical issue as this could happen only if you had a significant load and were not using transactions.
  • Better interaction with second level caching.
  • Performance fixes: when the DocumentId doesn't match the JPA id we now still execute an optimal database query.

Full details available in the Release notes.

For more information, please see:

Changes to 4.3.6.Final were mainly bugfixes with some performance improvements. A new Hibernate module was added to provide support for HikariCP connection pool (HHH-8869).

The following bugfixes applied only to 4.3.6.Final:

  • HHH-8818 fixed a regression introduced in 4.3.0.Final causing Hibernate to not be able to find the JNDI DataSource.
  • HHH-4700 fixed a bug using an HQL CASE expression containing a parameter in the THEN clause, and HHH-6747 fixed a bug rendering a SimpleCase using CriteriaBuilder.selectCase( arg ). Both caused ClassCastException to be thrown.
  • HHH-8885 fixed a bug causing a NullPointerException when MapJoin.key() is used.
  • HHH-8980 fixed a bug where an entity was not found if a joined subclass had a non-nullable many-to-one or one-to-one association.

The following bugfixes applied to both 4.3.6.Final and 4.2.15.Final:

  • HHH-9280 - caused the table name computed for an @ElementCollection to use the entity class name instead of the specified entity name.
  • HHH-8310 caused class loading problems due to a Spring bug that changed the context classloader to one that could not locate Hibernate Lob proxy classes (BlobProxy, ClobProxy, NClobProxy, SerializableBlobProxy, SerializableClobProxy).
  • HHH-9106 (for 4.3.6.Final) and HHH-9261 (for 4.2.15.Final) optionally allows multiple representations of the same entity to be merged (e.g., loaded from different sessions).

JBoss Nexus:
Maven Central: (should update in a couple of days)
4.3.6.Final Downloads: 4.3.6.Final ZIP, 4.3.6.Final TGZ
4.2.15.Final Downloads: 4.2.15.Final ZIP, 4.2.15.Final TGZ

It's my pleasure to announce a new release of Hibernate OGM.

Hibernate OGM can now convert JP-QL queries into cypher queries when working with Neo4j. We improved the JSON representation used for associations in CouchDB and MongoDB making it more concise. We also worked on several bug fixes and improvements under the hood, you can read more about it in the release note.

As always, you can either download a release bundle from SourceForge or retrieve the JARs from the JBoss Nexus repository server using Maven, Gradle etc. The GAV coordinates are:

  • org.hibernate.ogm:hibernate-ogm-core:4.1.0.Beta5 for the OGM engine and
  • org.hibernate.ogm:hibernate-ogm-<datastore>:4.1.0.Beta5, depending on the backend you want to use.

From JP-QL to Cypher

For example, if you execute the following JP-QL query:

from Hypothesis h where IN ('alma', 'alfred')

OGM will execute the following Cypher query on Neo4j:

MATCH (h:Hypothesis) WHERE ANY(_x_ IN ["alma", "alfred"] WHERE = _x_) RETURN h

The following subset of JP-QL constructs is available at the moment:

  • simple comparisons
  • the boolean operators AND, OR, NOT

More natural mapping for associations in MongoDB and CouchDB

In the previous releases, an entity with an association looked something like the following JSON:

   "_id": "4f5b48ad",
   "rows": [
           "bankAccounts_id": "7873a2a7"

We got rid of the name of the id in the rows field, this will now look like:

   "_id": "4f5b48ad",
   "rows": [

What's next?

Some work on the Neo4j side is still required to make the mapping of the entities more natural. We also want to add caching in several places to improve performance (OGM-541, OGM-515, OGM-522).

We are also discussing about a solution for the generation of error reports with the failed operations on non-transactional db.

You're very welcome to raise your voice on the mailing list, ask questions in the forum or report any bugs or feature requests in the issue tracker.

Showing 1 to 5 of 1214 blog entries