Interface for dirty-checking performed by the user to optimize SQL-Statements [DATAJDBC-345]

[spring-projects-issues]

Tobias Rojahn opened DATAJDBC-345 and commented

Hi,

from a discussion with Jens Schauder stems the following feature request:

Give the user an option to control, which entities inside an aggregate are updated on save, i.e. to provide information which entites have been changed. E.g. by providing an optional parameter for a functional interface to be passen on save or by having entites implement an interface.

This would enable to user to optimize performance (if he requires it) in terms of number of SQL statements as well as the volume of historization data that is created by changes.

Here is the full background information in german:

---

Hallo Jens,

ich versuche mal es darzustellen

-Historisierung ist ein Thema das immer mitschwebt. Wir arbeiten vor allem für Versicherungen und Banken und in den Systemen müssen nahezu alle Tabellen vollständig technisch historisiert werden.
-Wir halten Datenbank-Trigger für eine gute Lösung dafür, es gibt also keinen Bedarf dafür, dass der OR-Mapper ein entsprechendes Feature anbieten muss. Trigger haben vor allem auch den Vorteil dass kein Entwickler daran vorbei programmieren kann.
-Wenn ich Trigger auf Update und Delete zur Historisierung setze, hat das zur Folge dass nicht nur der Datenstand am Ende einer Transaktion sondern auch die konkret abgesetzten SQL-Befehle relevant sind. D.h. es macht einen Unterschied ob es DELETE+INSERT oder UPDATE ist.
-Bei einigen Systemen ist es sicher egal, ob ich hier unnötige Historiensätze schreibe, aber bei größeren Aggregates werden viele unnötige Daten geschrieben.
-Je nach Performance-Anforderungen können auch schon die unnötigen Update-Befehle an sich ein Problem sein.
-D.h. ich halte es für wichtig eine >optionale< Möglichkeit anzubieten, die Updates genauer zu steuern.

Ich denke wenn der Nutzer eine genaue Steuerung darüber möchte, welche Entitäten geändert werden, muss er selbst verwalten, was geändert wurde (sonst sind wir beim PersistenceContext von Hibernate, der versucht dieses Problem allgemein zu lösen). Meine Idee geht dahin, dass der OR-Mapper eine Schnittstelle anbieten müsste, um einen Mechanismus zum dirty-checking anzuschließen. Meine einfachste Idee wäre beim speichern einen optionalen "DirtyChecker" zu übergeben, der jedes Objekt einmal bekommt, um zu beantworten, ob es geändert wurde.

Bzgl. der 1:N Beziehungen: Wir bilden einen Versicherungsvertrag ab, der viele (1-50) einzelne Positionen beinhaltet. Es ist ein häufiger Use-Case das einzelne Positionen hinzugefügt, entfernt oder geändert werden.

---

best wishes

Tobias Rojahn

---

No further details from DATAJDBC-345