SpringData vs. MongoDB: an incompatible design

MongoDB is a very well-known NoSQL document database, while Spring is a well-known open source framework in the Java field. In addition to IoC and AOP that constitute the core of Spring, Spring also has a large number of sub-frameworks used in various fields, among which Spring
Data is a sub-project dedicated to data processing. Under Spring Data, there are Spring Data JPA, Spring Data
MongoDB, Spring Data Redis and other sub-projects can be seen from the name of the goals of these sub-projects. Among them, Spring Data
MongoDB is a sub-project specifically for MongoDB, which aims to manipulate MongoDB through Spring. Does this integration simplify development or hinder development?

Prashant Deva is the founder and CTO of Chronon. He is a serial entrepreneur who also founded Placid
Systems, AntlrStudio, and Virtual Ant. As a geek, Deva likes to try various new technologies. After using Spring
After working on Data MongoDB for a period of time, he believed that there were serious problems in the design of this framework, and wrote an article for an in-depth and detailed analysis.

Spring framework developers like to advertise their support for MongoDB everywhere, and use it as a capital advantage over other frameworks. However, if you use Spring
in a real project
In the case of Data MongoDB, you will find that the framework is seriously missing in some features and a huge mistake in design.

Spring Data
MongoDB tries to force the ORM-style architecture into a non-relational database, which directly leads to serious consequences that cannot be used in actual projects. Let’s talk about the reasons behind this:

Fields cannot be retrieved, only the entire document

This is Spring Data
The biggest flaw in MongoDB’s design. It tries to model documents with rows in a SQL database, and expects you to create “entity” classes like an ORM. The two are not the same thing at all. Documents are much more complex and larger than rows in an SQL database.

For the rows in the SQL database, it thinks that you will get all the data in it in most queries, otherwise the data should be divided into multiple tables. However, documents are completely different. Documents can be nested. Many times you only want to get a subset of documents from the database.

But for Spring Data MongoDB’s “entity” model, you have to retrieve the entire document in every query.

No DBRef lazy loading

This is even crazier. If you refer to other documents through DBRefs, then Spring Data
MongoDB will get the entire document instead of a document reference. If a large number of documents are joined via DBRefs, a simple query that only wants to get a few fields can result in the entire document graph being fetched!

The reality is that this bug report is almost two years old, has been assigned a “low priority” status, and has no resolution, which is unbelievable and shows that Spring
What a big gap there is between the vision of Data MongoDB and the actual use.

Cursors not supported

Do you want to traverse the collection with a cursor? no way. Either fetch the entire collection, or switch to the native Mongo Java driver.

Incomplete aggregation framework support

Spring Data
MongoDB has only recently supported the MongoDB Aggregation Framework, and like the rest of the framework, this support is a work in progress.

The framework documentation is sparse and confusing, and most of the aggregation queries required in actual projects cannot be implemented in Spring Data
Found in the MongoDB documentation, you can only use the native driver.

Poor indexing support

While a field can be marked as “indexed” by the framework, other operations simply don’t know about it.

Take an example in MongoDB, if a field is unique and sparse, then you cannot insert more than once into a document with a “null” value. This means that when inserting for the second time, the field should not appear at the position of the first insert.

However, since Spring forces you to define document fields in a class, you end up assigning null to non-existent fields. If the field has a unique sparse index, then this will cause a runtime error, because Spring does not know the existence of the index at all when creating the query against the entity object (defined directly on the field as an annotation).

Spring also provides a ensureIndex() method for manually creating an index on a field without using annotations, but the document does not mention when to use this method, how often it is used, and what the performance of the call is .

Unable to switch database

Many times, you want to store data in different databases of a single MongoDB instance, for example to keep different customer data separate.

If you use the native Mongo driver, switching databases is a piece of cake, just call getDb(dbName) directly. But if using Spring
Data
MongoDb, then this is almost an impossible thing to do, unless you are willing to write a lot of code yourself (but if you do this, it may be impossible after the new version of the framework is released.�� Emerging portability issues).

Strange logging framework

I’ve written a whole article on Spring’s documentation. Spring documentation says it’s using Jakarta Commons
Logging, but Spring Data obviously uses SLF4J. However, the Spring Data documentation doesn’t mention this at all.

This means that if you start using Spring
Data, then you may encounter a lot of runtime errors that are not mentioned in the documentation. At this time, there is no other way, so go to StackOverflow to find the answer.

The dynamic nature of the document is not supported

The biggest reason for using a document-oriented database like MongoDB is its dynamic nature. For example, documents in the same collection can be different, so that there can be multiple versions of documents in the same collection, and then gradually upgraded, and documents can also be nested. The key names do not have to be known in advance, so that property maps can be inserted directly into the document.

But the fact is that Spring Data
MongoDB discards this most basic feature of MongoDB, and tries to build a definite, pre-defined ORM-style layer on top of it, which directly creates a mismatch between the framework and the underlying database.

Conclusion

Spring Data
MongoDB seems to have been designed by people who have never used MongoDB in a real project at all, and it’s an attempt to shoehorn a document-oriented database into an ORM-style framework.

This leads to a mismatch between the framework and the database, Spring Data
MongoDB has become a burden instead of helping us simplify development. In the end, you still have to use native MongoDB in almost all real project development
Java driver.

Postscript

Dear InfoQ readers, have you ever used Spring Data MongoDB for MongoDB development?
How does it feel to use Data MongoDB? Is it consistent with Deva’s experience? I have tried Spring Data in my project
MongoDB, an intuitive feeling after using it is that it complicates simple things. It is a very simple and intuitive process to directly use the native Java driver to manipulate MongoDB, and Spring
Data
However, MongoDB continues to use its long-standing processing style, that is, IoC. It needs to be injected first, and then obtain the required objects from the container, which makes the original easy operation complicated. I don’t know how readers feel. , welcome to discuss.

from infoq