Introduction

In this article, we are going to see why the Spring Data findAll method is actually a terrible Anti-Pattern.

A picture is worth 1000 words:

You’d be surprised how many times I’ve seen this issue where tons of data was fetched from the DB just to filter it in Java and throw away the vast majority of records that were not needed for that particular business requirement.

Anti-Pattern

First, let’s start with the Anti-Pattern definition, as given by Wikipedia:

An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

That’s exactly what you get when you offer a findAll method in the Spring Data Repository base interface that all Data Access Objects will automatically inherit.

The Spring Data Repository hierarchy

Usually, when you create a Spring Data JPA Repository, your custom interface extends the JpaRepository:

However, the JpaRepository provides a series of methods that it either declared directly or inherited from the underlying base interfaces, as illustrated by the following diagram:

Even if the JpaReository didn’t provide a findAll method explicitly, it would still inherit one from the CrudRepository that’s shared by all Spring Data modules.

The Spring Data findAll Anti-Pattern

The problem with the findAll method is that, as an API designer, you should not really offer your clients a way to fetch an entire database table because, if you do, some developers are actually going to do that.

Let’s assume we have the following Post and Tag entities in our system:

We want to get the titles of all the JDBC or Hibernate posts, so how can we do that?

The easiest way is, of course, to use a single SQL query that looks as follows:

But, not every Java developer enjoys solving this problem using a simple SQL query. Some of them will do whatever is humanly possible to avoid writing any SQL query.

And, since we are just one findAll method call away from “solving” this issue, it won’t take long until someone provides the following solution:

When executing the findAll workaround, Hibernate will execute the following queries:

Not nice!

The reason why you see so many secondary queries is due to filter predicate that needs to fetch the tags collection in order to match the provided tags.

Preventing the Spring Data fetchAll Anti-Pattern

The findAll method should not be offered by default, and that’s why the HibernateRepository from the Hibernate Types project, deprecates it.

More, if you call it, it will throw an UnsupportedOperationException.

To make sure the findAll method is never called by mistake, just make your Repository classes extend the HibernateRepository interface:

The HibernateRepository needs to precede the JpaRepository as otherwise, IntelliJ IDEA will not strike through the findAll method call.

And, we also have to provide the com.vladmihalcea.spring.repository package to the @EnableJpaRepositories annotation:

This way, you will instantly see that the findAll method is to be avoided since it’s striked through now:

However, if you know for sure that for specific use cases it’s fine to have a findAll method, then you can simply override it as follows:

This way, you will explicitly specify that the findAll method is really needed, although I doubt this will be the case in most non-trivial applications.

For more details about the HibernateRepository, check out this article.

The Hibernate implicit polymorphic query Anti-Pattern

The findAll Anti-Pattern reminds me of a lesser-known “feature” of Hibernate that allows you to select the entire database with a single query:

The reason why this query works is because of the implicit polymorphic query feature offered by Hibernate. The reason why you haven’t seen this Anti-Pattern used in practice is that the Hibernate developers didn’t think it was a good idea to encourage fetching the entire database at once, so they omitted it from the documentation.

Internally, Hibernate team actually used such a query during testing:

But, since this was limited to the Hibernate integration tests, there was no problem using such a dangerous query. And, what’s interesting is that not all Hibernate tests used it. Some of Hibernate integration tests were simply dropping and recreating the DB schema in between tests, so there was no point in deleting all records.

I'm running an online workshop on the 15th of September about High-Performance SQL.

If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.

Conclusion

The Spring Data findAll method follows exactly the Wikipedia definition of an Anti-Pattern, and it’s much better if you avoid it by default because, this way, you can prevent some very inefficient data access operations that will probably be overlooked until you have enough data in your production system.

Nevertheless, just because you deprecated the default findAll method, it doesn’t mean you cannot explicitly declare it. However, this way, you will tell other developers that you really know what you are doing, and you can still enjoy loading an entire database table in your application memory.

So, going back to the definition of an Anti-Pattern:

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

We can conclude that the findAll method is ineffective and risks being highly counterproductive, and if you offer it by default, then it risks becoming a common response to a recurring problem.

This site uses Akismet to reduce spam. Learn how your comment data is processed.