CODEWITHSUNDEEP
springmongodbjpaspring-datadatabase
smuggledPancakes
smuggledPancakes

Reputation: 10333

Does MongoDB work with JPA?

I am new to working with databases, so my question is probably naive. I currently have a project using Spring Data with JPA. I am using Hibernate and MySQL under the hood. Is it possible to switch to MongoDB? When I googled "jpa MongoDB" the top link showed something interesting (DataNucleus JPA and MongoDB). This link: MongoDB docs appears to show that the Java driver is JPA compliant, so should it be simple to swap out database implementations?

Upvotes: 22

Views: 31655

Answers (4)

Oliver Drotbohm
Oliver Drotbohm

Reputation: 83151

It highly depends on your definition of "work". "Generally work"? - Yes. "Reasonably work" - depends. "Works seamlessly" - not so much.

JPA is an inherently relational API, so be prepared you run into these aspects:

  1. JPA is not supporting a lot of the features MongoDB exposes. Geo-spatial functionality, upserts etc. You're going to need custom extensions for that which minimizes the benefit of using JPA in the first place.
  2. A lot of stuff available in JPA doesn't make any sense in a MongoDB (non-relational world) and won't be supported. Transactions? What's a join colum supposed to be in MongoDB? The former not being available is pretty dangerous actually. What's supposed to happen if a JPA developer calls transaction.rollback()? Strictly speaking, you can't implement JPA 100% (by definition) and most of the self-proclaimed JPA implementations for NoSQL are basically providing a tiny subset of JPA: some of the annotations for mapping, some of the EntityManager API.
  3. Simply switching the store behind an object model is a fallacy, too. Especially NoSQL stores are built in a way to favor certain data structures (MongoDB's good for documents, Neo4j for highly interconnected data). That means that you'll model the domain code and the converters differently based on what store you actually use. Switching stores arbitrarily will lead you to reduce your domain model to the least common denominator and basically make less use of the features that might have made you select the store in the first place.

While I can see the incentive to put a familiar API over something new to gain some kind of knowledge transfer but ultimately think this is a fallacy if the target space doesn't support key aspects (e.g. transactions). All of the approaches I've seen so far end up spending a huge part of their documentation to document what's not supported for both the JPA and the store side of things.

That said, there are other approaches moving away from "one API to rule them all" and proactively leveraging the diversity in the NoSQL space (think about it: a set of technologies defined by what they are not will be quite diverse by definition).

The Spring Data project (disclaimer: I am the lead of this) is moving up one level of abstraction and rather provides a consistent repository programming model that than one, unifying API. This allows still providing support for store specific functionality but the general means of use stay the same.

So I suggest to move to the dedicated Spring Data MongoDB project here.

Upvotes: 35

Neil Stockton
Neil Stockton

Reputation: 11531

Yes, DataNucleus JPA allows it, as well as to many other databases. You make compromises by using the JPA API for other types of datastores, but it makes it easy to investigate them.

Upvotes: 2

Brian Vosburgh
Brian Vosburgh

Reputation: 3276

EclipseLink extends JPA to support MongoDB: https://wiki.eclipse.org/EclipseLink/Examples/JPA/NoSQL

Upvotes: 2

Hatem Jaber
Hatem Jaber

Reputation: 2402

You should be able to swap them out with a little work. Here is an example guide from the Spring.io site: Accessing Data with MongoDB

Instead of using a JPA Repository, you will use a Mongo Repository... The sample should be enough to give you an idea.

Upvotes: 3

Related Questions