Improve strategy for persisting referenced entities [DATAJDBC-210]

[spring-projects-issues]

trafficstars

This is an Epic gathering various approaches to improve the writing behaviour of Spring Data JDBC.

If we have an Aggregate Root A referencing entities B on update the following SQL statements get executed:

• delete all previously referenced Bs
• update A
• insert all now referenced Bs

We should improve this in multiple ways:

1. Use upserts on Bs and only delete those not longer present
2. ~~Use batched statements for inserts (and updates)~~ This is implemented.
3. Allow detection of changed Bs. There are various possibilities how to do this
   • have an annotated attribute carrying this information
   • wrap everything in proxies to track this (I really don't like this because I think it's opening a can of worms)
   • one way or the other compare with the version currently in the database. Not sure how to do that, possibly with a JDBC specific API

Also, performancetests would be nice and probably a good first step.

Create separate issues to work on any of these. Use this issue to discuss these and other strategies to improve persisting performance.

Jens Schauder opened this ticket as DATAJDBC-210

[spring-projects-issues]

Anton Reshetnikov commented

+1 for

2. Use batched statements for inserts (and updates)\

I was going to create separate issue for batched jdbc operations in Spring DATA JDBC, but found this issue

[spring-projects-issues]

Jens Schauder commented

Anton Reshetnikov batch inserts will have to wait until we have proper support for Id generation strategies, because the current one (via SERIAL/AUTOINCREMENT in the database) does not work with batches. See https://github.com/spring-projects/spring-framework/issues/6530

[Husan]

+1 for 1 st and 3.1

1. Use upserts on Bs and only delete those not longer present 3.1. have an annotated attribute carrying this information

I think that the 1 st option must be default behavior or may be switched on by some annotation on Aggregate Root. 2 nd option may be must be behavior when developer define which row must be updated which insert and which must be deleted. May be similar to isNew function must be changeOperation(or changeType) function in child aggregate which must be implemented from some interfays(like Persistable) and return values as "INSERT", "UPDATE", "DELETE", "NONE"(means non operation must be performent on reference collection element). Example:

class AgregateRoot implements Persistable{
     .........
     @UpdateStrategy("UPSERT")
     Set<ChileAggregate> aggregate;
}

class ChildAggregate implements SomeInterface{
       .......
      public changeType(){
              return "UPDATE";
      }
}