JPA and Spring Data

I have already published several articles on spring data and I will be building from them. If you have not read the previous one, I recommend you give it a look. We already looked at what Spring Data is and its relationship to JPA and Hibernate.

I am going to be having a series of articles under spring data, The series will contain the following :

1.????Derived queries & JPQL

2.????Projection and their types

3.????Spring Expression language with Spring Data

4.????Modifying queries

5.????Avoiding the N+1 problem

6.????Stored procedures

7.????Named Queries

8.????And more topics

This article is probably going to handle just the first bullet point.

Before we go on, you might want to know why to use Spring Data. The following are some of the reasons

1.????Reduced boiler plate code

2.????Generation of queries based on method names

3.????No code repositories, which hide data store specific details. Imagine, you just have an interface deriving from spring repository and hey presto, you have a bunch of useful methods implemented for you. That is beautiful right? Thanks to Spring Data development team.

You probably heard about derived queries with spring haven’t you? Spring recommends to use them as much as you can to leverage Spring Data to generate queries for you are runtime. Derived queries in Spring are generated based on method names. This is part of the abstraction that Spring Data has on top of a JPA provider. This is a Spring feature not a provider feature.

And Spring has a style which you have to follow to write them such as find…By(), read..By(), query…By(), get...By(), delete..By() etc. For example, look at the following query. Assuming Person has a list of addresses and an address is a separate entity. They have a one to many relationship.

This method results in a query that spans multiple entities. This query traverses an association Address and it will be translated into the below SQL query:

SELECT * FROM person 

LEFT JOIN address a

ON ?p.id = a.user_id

WHERE a.city LIKE ? ESCAPE

LIMIT ?        

I assume most developers are already familiar with this and I don’t want to bore my audience with information they already know. So, let me pass this topic on derived queries. But before I do so, let me give some rules of thumb regarding their use. The method name above is a bit long under the premise that it improves readability. Well, you can argue that a method name is allowed to reach as far as 65536 and if the language allows it, why can’t I use it?

Long method names is an indicator we are trying to do a lot or too much in one method and it is a code smell. The only time you are allowed to write a method name that is so long enough that it can fill the gap between Russia and China, is when you are wring a test method. There are no limits there :). But you can still argue that although the method seems to be shouting many responsibilities, it is actually not because it only has one parameter passed to it. Spring does give us a way out from this problem by allowing us use either native or JPQL with the help of @Query.

Before I give too much info that will possible make this article very long and I want to avoid that, there are rules of thumb regarding derived queries.

1.????Avoid long method names

2.????Your method should have a maximum of two parameters.

3.????Where you have more than two params use JPQL.

Before I pass this, allow me to mention that you should prefer bind parameters over inline params, as they avoid SQL injections. They also allow automatic conversion to correct SQL types. Finally, they enable JPA provider and database to optimise the query for you.

Now let’s talk about JPQL, Java persistence query language.

It enables you to write queries based on your domain models, and this lets JPA provider handle different database dialects so that the query is database agnostic.

Downside of JPQL

1.????It supports only a subset of SQL standards, it does not cover everything.

2.????It is not a great fit for very complex queries. I have often heard people say, “I HATE JPA”.

Let me mention that JPA can be very problematic when you have not explored it much. You get a lot of issues such as N + 1 problem, infinite recursion for entities which have a bidirectional relationship and so on. Not going to talk about these JPA issues for now, I will probably have a separate article for that.

I had intended to give more on this, it’s a Saturday and I have something to do now, I have to stop here. Please do have a wonderful day. I will produce series 2 which will be a continuation of this article. As always, please do not forget to subscribe to my channel. I will also be producing videos on Spring Data.

As always, please subscribe to this channel. More content on Spring is coming.

https://www.youtube.com/channel/UC5BkBVEep9_jc54l9W_SW0g