1. Introduction
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're going to 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 that we can not supply partial data. That can become inconvenient, especially for larger objects with a lot of fields.
If we'd look at an ORM, some patches exist, like:
- Hibernate's @DynamicUpdate annotation, which dynamically re-writes the update query
- JPA's @Column annotation, as we can disallow updates on specific columns using the updatable parameter
But in the following, we're going to approach this problem with specific intent: Our purpose is to prepare our entities for the save method without relying on an ORM.
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.
Though this is simple and obvious, it's of the simplest approaches we can use.
Let's add a method in our service to update the contact data of our customers.
public void updateCustomerContacts(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 a large number of fields with different access levels, it's quite 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 bothersome, and pretty unmaintainable.
Nevertheless, we can get over this issue using a mapping strategy, and 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 also 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 from 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 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
At last, keep in mind 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. What if we 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 having to retrieve and fill 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 overengineering.
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, which 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 in 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 updateCustomerContacts(long id, String phone) {
repo.updatePhone(id, phone);
}
Now we are able to perform a partial update: with just a few lines of code and without altering our entities we've achieved our goal.
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 to handle it, sometimes it could 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 over on GitHub.