Speicherlogik, Transaktionskonzept der Anwendung

[Dr-Thomas-Tensi]

Es ist für mich nicht klar, welche Transaktionslogik beim Editieren von Objekten gilt. Das Navigationsdokument schlägt vor "Formular=Transaktion", man könnte aber auch sofort beim Focus_Lost implizit speichern.

Wenn man aber das Formular als Transaktionseinheit ansieht, dann müsste bei jedem Dialogwechsel zu einem Partnerobjekt gespeichert werden. Was passiert dann, wenn man inline Attribute in einer Partnerobjekttabelle ändern kann: ist das auch ein Transaktionsende oder eine geschachtelte Transaktion? Oder gar nicht erlaubt?

Nehmen wir an, wir lösen das über geschachtelte Transaktionen: wie tief darf das gehen? Ein Objekt und sein Partnerobjekt? Oder beliebig tief?

[ejcsid]

@xdoo @dragonfly28 @rowe42 @Baumfrosch @ejcsid

[xdoo]

Es ist grundsätzlich alles erlaubt. Es wird nur nicht alles out of the box unterstützt. Es gibt hier auch keine pauschale Antwort, weil sich eine Entität mit Relationen im Transaktionsverhalten von einer Entität ohne Relationen unterscheidet.

Wenn du dir die Anwendung anschaust und die Dev Tools deines Browsers nutzt, dann kannst du ganz genau sehen, wann Daten gespeichert werden.

[Dr-Thomas-Tensi]

Es ist grundsätzlich alles erlaubt. [...] Es gibt hier auch keine pauschale Antwort, weil sich eine Entität mit Relationen im Transaktionsverhalten von einer Entität ohne Relationen unterscheidet.

Das ist schon ein valider Punkt, aber wollen wir die Transaktionslogik wirklich komplett den Vorhaben überlassen? Zumindest eine Style-Guide-Vorgabe wäre sinnvoll und die wird sicher solche Situationen, wie Du Sie beschreibst, im Einzelnen betrachten müssen.

[die Anwendung implementiert eine nachvollziehbare Speicherlogik]

Davon bin ich überzeugt, aber eine Standardisierung - gerne auch auf verschiedene zulässige Blaupausen - fände ich sinnvoll.

Vorschlag: wir können ja mal sehen, wie die Pilotanwendungen mit dem Transaktionsthema umgehen und dann - basierend auf den Erfahrungen - standardisieren.

[rowe42]

Mir ist derzeit nicht bekannt, wie man vom Frontend aus mehrere REST-Calls unter eine Transaktionsklammer packen könnte (so mit Rollback usw.). D.h. aber, wenn man z.B. will, dass es eine Transaktion über Anlage von Animal inklusive neu anzulegendem Keeper gibt, müsste man dafür wohl einen eigenen REST-Call ins Backend einbauen, oder (@xdoo )? Das hielte ich zum aktuellen Zeitpunkt für unverhältnismäßig aufwändig. Ich würde dann vorschlagen, dass wir nehmen, was das Backend derzeit unterstützt - selbst wenn das teilweise problematisch ist, z.B. sind es 2 Transaktionen, wenn man bei einem Animal die Attribute updaten und gleichzeitig einen neuen Keeper anhängen möchte - obwohl wir das beim aktuellen GUI-Design an einen einzigen Klick auf Speichern hängen.

[rowe42]

@Dr-Thomas-Tensi Kannst du dir bitte meinen letzten Kommentar anschauen und beurteilen, ob wir das Issue (erstmal) schließen können?

[rowe42]

Aus Diskussion mit @Baumfrosch: Entscheidend ist, dass bei einem Backend-Interaktion immer ein wieder konsistenter Zustand nach atomarer Aktion entsteht. Das ist m.E. derzeit gegeben. Wir schieben das auf MS 4. Bitte trotzdem prüfen, ob wir es nicht ganz schließen können. @Dr-Thomas-Tensi

[Dr-Thomas-Tensi]

@rowe42 Aus der Diskussion mit Dir von vor zwei Tagen: die derzeitig implementierte Transaktionsidee ist zunächst einmal ausreichend. @olympialice und ich machen uns Gedanken, ob "Speichern" und "Zwischenspeichern" eigentlich dieselbe Aktion sind (d.h. in jedem Fall eine vollständige Validierung durchlaufen wird) und zumindest beim Zwischenspeichern kein Kontextwechsel stattfindet. Die entsprechenden Interaktionsmodelle werden wir ausarbeiten und in der Gruppe vorstellen.