Hibernate OGM FAQ
Hibernate OGM FAQ
You’ve got a question burning you? We might have the answer for you.
- Design for Hibernate OGM
- Using Hibernate OGM
- Developers of Hibernate OGM
Because Hibernate OGM is so well designed that you get it right away.
More seriously, this is a work in progress. If you have questions that you feel should be there, contact us.
That’s the million dollars question but in essence, yes we think it is a good fit. Here is quickly a few key reasons why JPA makes sense.
- Benefits of the abstraction level
JPA abstracts persistence at the object level, leaving room for a lot of tricks and optimizations. To name a few, think about declarative data / schema migration, declarative denormalization, polyglot persistence. Polyglot persistence is particularly interesting: storing data in several datastores and use the best one for a specific read job.
Of course if your dataset is by nature non domain model centric, then Hibernate OGM is not for you.
- Things just fit
While we were skeptic initially, most of the logical model of JPA fit. For example, an
@ElementCollectionnicely fit the document datastore approach of nesting related objects.
We work hard in Hibernate OGM to use the most natural mapping for a given data pattern and we offer you the ability to override that if needed.
- Known semantic and APIs
For better or worse, JPA is known to Java developers. They are familiar with its API and semantic. That’s a huge win compared to learning a specific lower level API or worse some pseudo-ORM level API. And we support both HQL and native backend queries!
- Late backend choice
Choosing an NoSQL engine is not trivial. Having the freedom to switch backends without having to rewrite all of your data layer is certainly something to appreciate.
Like Hibernate ORM, Hibernate OGM is orthogonal and agnostic to transactions, but integrates the flush event to them when possible.
Make sure to demarcate your transaction either via your application container or via the Hibernate OGM transaction demarcation methods. The reference documentation details how to set up Hibernate OGM in various transaction environments.
Note that even if your datastore does not support transactions, we recommend you use transaction demarcations with Hibernate OGM to trigger the flush operation transparently (on commit). But do not consider rollback as a possibility, this won’t work.
Most likely, you forgot to demarcate the transactions or manually call
Even if your datastore does not support transactions, we recommend you use transaction demarcations with Hibernate OGM to trigger the flush operation transparently (on commit). But do not consider rollback as a possibility, this won’t work.
There are three main methods:
using Hibernate Search as indexing engine and use full-text queries
using JP-QL (we convert it into a native backend query)
pass a native backend query and bind it to the entity
The reference documentation details the various options.
In case you’re are seeing a
JndiException saying "Unable to lookup JNDI name [---PlaceHolderDSForOGM---]", your application likely cannot access the application server module(s) of Hibernate OGM.
To change this, add the following line to the META-INF/MANIFEST.MF file of your archive (adapt it to match your chosen datastore):
Dependencies: org.hibernate:ogm services, org.hibernate.ogm.mongodb services
Alternatively, you can configure this via the descriptor jboss-deployment-structure.xml. See the reference guide to learn more.
To skip all tests (from the core suite) for example related to associations, add this configuration to the Maven Surefire plugin:
<excludes> <exclude>**/associations/**/*Test.java</exclude> </excludes>
So the plugin configuration can look like:
<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <excludes> <exclude>**/associations/**/*Test.java</exclude> </excludes> <forkMode>once</forkMode> </configuration> </plugin> </plugins> </build>