CODEWITHSUNDEEP
springspring-dataspring-data-jpa
Martin Häusler
Martin Häusler

Reputation: 7286

How to correctly use Spring Data Repository#save()?

In Spring Data Repository interfaces, the following operation is defined:

public T save(T entity);

... and the documentation states that the application should continue working with the returned entity.

I know about the reasoning behind this decision, and it makes sense. I can also see that this works perfectly fine for simple models with independent entities. But given a more complex JPA model with lots of @OneToMany and @ManyToMany connections, the following question arises:

How is the application supposed to use the returned object, when all the rest of the loaded model still references the old one that was passed into save(...)? Also, there might be collections in the application that still contain the old entity. The JVM does not allow to globally "swap" the unsaved entity with the saved one.

So what is the correct usage pattern? Any best practices? I only encountered toy examples so far that do not use @OneToMany or @ManyToMany and thus don't run into this issue. I'm sure that a lot of smart people thought long and hard about this, but I can't see how to use this properly.

Upvotes: 0

Views: 548

Answers (1)

manish
manish

Reputation: 20135

This is covered in section 3.2.7.1 of the JPA specification that describes how merge should work. In a nutshell, if the instance being saved is managed (existing), it is simply saved in-place. If not, it is copied to a managed instance (which may not necessarily be a different object since the spec does not mandate that a new instance must be created in this case) and all references from the instance being saved to other managed entities are also updated to refer to the managed instance. This of course requires that the relationships have been correctly defined from the entity being saved.

Indeed, this does not cover the case of storing an entity instance in an unmanaged collection (such as a static collection). That is anyways not advisable because a persisted entity must always be loaded through the persistence provider mechanism (who knows the entity instance may have changed in the persistent store).

Since I have been using JPA for the past many years and have never faced problems, I am confident that the section I have referenced above works well in all scenarios (subject to the JPA provider implementing it as intended). You should try some of the cases that worry you and post separate questions if you run into problems.

Upvotes: 1

Related Questions