1. Overview
Spring Data’s CrudRespository#save is undoubtedly simple, but one feature could be a drawback: It updates every column in the table. Such are the semantics of the U in CRUD, but what if we want to do a PATCH instead?
In this tutorial, we will cover techniques and approaches to performing a partial instead of a full update.
2. Problem
As stated before, save() will overwrite any matched entity with the data provided, meaning we cannot supply partial data. That can become inconvenient, especially for larger objects with many fields.
We can act directly on the specific entity we need to update in two different ways:
- We can rely on Hibernate’s @DynamicUpdate annotation, which dynamically rewrites the update query
- We can use the updatable parameter on the JPA’s @Column annotation, which will disallow updates on specific columns
This approach will have some downsides. We specify the update logic directly on the entity, thus linking business logic and the persistence layer. More specifically, every update on the annotated entity will behave similarly.
In this article, we will see how we can solve this problem optimally without relying on the Hibernate or JPA annotation directly on the Database Entity.
3. Our Case
First, let’s build a Customer entity:
@Entity
public class Customer {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public long id;
public String name;
public String phone;
}
Then we define a simple CRUD repository:
@Repository
public interface CustomerRepository extends CrudRepository<Customer, Long> {
Customer findById(long id);
}
Finally, we prepare a CustomerService:
@Service
public class CustomerService {
@Autowired
CustomerRepository repo;
public void addCustomer(String name) {
Customer c = new Customer();
c.name = name;
repo.save(c);
}
}
4. Load and Save Approach
Let’s first look at an approach that is probably familiar: loading our entities from the database and then updating only the fields we need. It’s of the most straightforward approaches we can use.
Let’s add a method in our service to update our customers’ contact data.
public void updateCustomer(long id, String phone) {
Customer myCustomer = repo.findById(id);
myCustomer.phone = phone;
repo.save(myCustomer);
}
We’ll call the findById method and retrieve the matching entity. Then we proceed and update the fields required and persist the data.
This basic technique is efficient when the number of fields to update is relatively small, and our entities are rather simple.
What would happen with dozens of fields to update?
4.1. Mapping Strategy
When our objects have many fields with different access levels, it’s pretty common to implement the DTO pattern.
Now suppose we have more than a hundred phone fields in our object. Writing a method that pours the data from DTO to our entity, as we did before, could be annoying and unmaintainable.
Nevertheless, we can resolve this issue using a mapping strategy, specifically with the MapStruct implementation.
Let’s create a CustomerDto:
public class CustomerDto {
private long id;
public String name;
public String phone;
//...
private String phone99;
}
And we’ll also create a CustomerMapper:
@Mapper(componentModel = "spring")
public interface CustomerMapper {
void updateCustomerFromDto(CustomerDto dto, @MappingTarget Customer entity);
}
The @MappingTarget annotation lets us update an existing object, saving us the pain of writing a lot of code.
MapStruct has a @BeanMapping method decorator that lets us define a rule to skip null values during the mapping process.
Let’s add it to our updateCustomerFromDto method interface:
@BeanMapping(nullValuePropertyMappingStrategy = NullValuePropertyMappingStrategy.IGNORE)
With this, we can load stored entities and merge them with a DTO before calling the JPA save method — in fact, we’ll update only the modified values.
So, let’s add a method to our service, which will call our mapper:
public void updateCustomer(CustomerDto dto) {
Customer myCustomer = repo.findById(dto.id);
mapper.updateCustomerFromDto(dto, myCustomer);
repo.save(myCustomer);
}
The drawback of this approach is that we can’t pass null values to the database during an update.
4.2. Simpler Entities
Finally, remember that we can approach this problem from the design phase of an application.
It’s essential to define our entities to be as small as possible.
Let’s take a look at our Customer entity.
We’ll structure it a little bit and extract all the phone fields to ContactPhone entities and be under a one-to-many relationship:
@Entity public class CustomerStructured {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Long id;
public String name;
@OneToMany(fetch = FetchType.EAGER, targetEntity=ContactPhone.class, mappedBy="customerId")
private List<ContactPhone> contactPhones;
}
The code is clean, and, more importantly, we achieved something. Now we can update our entities without retrieving and filling all the phone data.
Handling small and bounded entities allows us to update only the necessary fields.
The only inconvenience of this approach is that we should design our entities with awareness without falling into the trap of over-engineering.
5. Custom Query
Another approach we can implement is to define a custom query for partial updates.
In fact, JPA defines two annotations, @Modifying and @Query, that allow us to write our update statement explicitly.
We can now tell our application how to behave during an update without leaving the burden on the ORM.
Let’s add our custom update method to the repository:
@Modifying
@Query("update Customer u set u.phone = :phone where u.id = :id")
void updatePhone(@Param(value = "id") long id, @Param(value = "phone") String phone);
Now we can rewrite our update method:
public void updateCustomerWithCustomQuery(long id, String phone) {
repo.updatePhone(id, phone);
}
We are now able to perform a partial update. We’ve achieved our goal with just a few lines of code and without altering our entities.
The disadvantage of this technique is that we’ll have to define a method for each possible partial update of our object.
6. Conclusion
The partial data update is quite a fundamental operation; while we can have our ORM handle it, it can sometimes be profitable to get full control over it.
As we’ve seen, we can preload our data and then update it or define our custom statements but remember to be aware of the drawbacks that these approaches imply and how to overcome them.
As usual, the source code for this article is available on GitHub.
