After a huge push, we are now one release away from our Final version. So without further due, I present you Hibernate OGM 4.1.0.CR1. To sum it up:
- stable mapping for each of the supported datastores (Infinispan, Ehcache, MongoDB, Neo4J)
- new and better one cache per entity structure for key/value stores
- improvement in Neo4J and MongoDB around embedded objects and composite ids
- better documentation
Our goal for Hibernate OGM 4.1 is to offer a good Object Mapper for each of the primary datastores we target. Go test it before the final and give us feedback!
- zip release bundle
- Maven repository server
- getting started guide and reference documentation
- user forum
Mapping stability and documentation
This CR release signals the stable version of how we persist each data structure on the various datastores. We strive to offer a mapping that is natural to each individual datastore. We made some final improvements and are confident we can support this version.
For each datastore, we documented how each JPA mapping is persisted (entities, star-to-one, star-to-many, embedded id, etc.). It makes for a tree-killer documentation but shows what is the truth for each mapping.
We took the opportunity to improve the documentation even further and plan to finish that work for the final version.
Additional key/value cache structure
Our tests have showed that storing each entity type and association in a dedicated cache is actually more efficient than sharing the same cache for all entities. Since we also think it is a more natural mapping, we now offer this option and make it the default.
A User and an Address entities would lead to the following caches:
- User: contains the users
- Address: contains the address
- associations_User_Address: contains the navigation from a user to its list of addresses
An interesting side effect is that it makes the keys smaller in size and faster to compare. Both Infinispan and Ehcache are benefiting from this.
Improvements around embedded objects, embedded ids and properties
In Neo4J, (non id) embedded objects are now represented as individual nodes. It is more in line with the connection behavior of graph databases.
In MongoDB, embedded id foreign keys have been improved and are now represented as nested documents like embedded ids were already. We did not hear complains about this one, so we think you guys don't use composite ids with MongoDB. That's good, keep doing that :)
The null properties are no longer stored in any of the data stores. While it might make some queries involving null values a bit harder, it is the more natural mapping for the datastores.
