Add support for upserts [DATAJDBC-281]

[spring-projects-issues]

Erik Petzold opened DATAJDBC-281 and commented

Currently the decision for insert or update is based on the value of the Id field. If there is a value, then an updated is performed, if there is null, an insert is performed.

This implies, that the id is set afterwards (by database or by an eventlistener), which makes it hard to use an existing field with a value from business domain as id. These things would never get inserted as the framework thinks they already have an Id and need an update.

There are several people having issues with that, see https://stackoverflow.com/questions/52771309/how-to-insert-a-record-with-custom-id-use-spring-data-jdbc or https://stackoverflow.com/questions/50371775/why-does-spring-data-jdbc-not-save-my-car-object

The proposed workaround to use an eventlistener to set the Id after the decision for insert vs update would allow copying the value from another field to the Id and might work in some cases. Still it is complicated, especially if there are many classes that need to be persisted.

Then there is another use case, where messages are consumed and the payload needs to be persisted, either inserting or updating data. Here also the eventlistener approach with setting the Id field would not work, because it leads to Exceptions with duplicate entries. We would need to check if the entry already exists before setting the Id.

Here a simple upsert solution provided by spring-data-jdbc would really help in easily persisting the data from the messages.

 

There are also other places, where people ask for that, like in the comments of you blog article http://disq.us/p/1wr6mgn and http://disq.us/p/1vyubm8

---

Affects: 1.0.1 (Lovelace SR1)

Issue Links:

• DATAJDBC-282 Dedicated insert and update methods in the JdbcRepository
  ("is duplicated by")

[spring-projects-issues]

Erik Petzold commented

I just found out there is already a similar ticket here: DATAJDBC-269, so maybe this can be closed as duplicate

[spring-projects-issues]

Jens Schauder commented

Yes indeed

[spring-projects-issues]

Jens Schauder commented

Batch closing resolved issues without a fix version and a resolution that indicates there is nothing to be released (Won't Do, Won't Fix, Invalid ...)