Staging & Commit

Jede Bearbeitung in DynoTable läuft durch einen Staging-Bereich, bevor sie DynamoDB berührt. Stell ihn dir als git-Staging-Bereich mit Sicherheitsriegel vor: Bearbeitungen, Erstellungen und Löschungen sammeln sich als prüfbare Diffs an und gehen erst beim Commit als transaktionale Batches raus.

Nichts wird in deine Tabelle geschrieben, bis du es sagst.

Wie es funktioniert

Jede Tabelle hat ihren eigenen Staging-Bereich, geteilt über jede Ansicht dieser Tabelle. Wenn du eine Item-Bearbeitung speicherst, eine Zeile erstellst oder eine löschst, landet die Änderung im Panel als attributweises Diff — hinzugefügte, entfernte und geänderte Attribute nebeneinander gezeigt. Betroffene Zeilen im Raster werden nach Operation eingefärbt:

• grün — ein neues Item (Erstellen)
• orange — eine Aktualisierung (geänderte Zellen hervorgehoben)
• rot — eine Löschung (durchgestrichen)

Öffne dieselbe Tabelle in zwei Tabs und beide zeigen dieselben ausstehenden Änderungen; schließe und öffne einen Tab erneut, und das Stage ist noch da. Das Schließen eines Tabs verwirft deine vorbereiteten Änderungen nie.

Schalte das Panel mit ⌘⇧D ein/aus. Zieh an seinem Rand, um es in der Größe anzupassen.

Änderungen prüfen

Jede Diff-Karte zeigt genau, was sich ändert:

• Skalare werden alt → neu mit roter/grüner Hervorhebung gerendert.
• Lange Strings zeigen ein Inline-Wort-für-Wort-Diff.
• Maps und Lists werden als hübsch formatiertes JSON gerendert (ganzes Attribut in v1).

Nutze das attributweise Ablehnen einer Karte, um ein einzelnes Attribut auf seinen ursprünglichen Wert zurückzusetzen. Lehne jedes Attribut ab, und die ganze Änderung wird verworfen.

Committen

Committe, um deine vorbereiteten Änderungen in DynamoDB zu schreiben:

• N committen schickt jede vorbereitete Änderung dieser Tabelle raus — über alle ihre Tabs hinweg.
• Nur dieses committen schickt eine einzelne Änderung von ihrer Karte raus.

Commits gehen als TransactWriteItems-Batches mit optimistischen-Locking-Bedingungen raus: eine Aktualisierung gelingt nur, wenn die Attribute noch die Werte halten, mit denen du begonnen hast, ein Erstellen gelingt nur, wenn das Item nicht bereits existiert, und ein Löschen gelingt nur, wenn das Item noch da ist. Große Stages werden automatisch zerteilt, um innerhalb der Transaktionslimits von DynamoDB zu bleiben.

Die Speicher-Tastenkombinationen aus dem Editor gelten auch hier:

• ⌘S — vorbereiten (kein Commit)
• ⌘⇧S — speichern & committen
• ⌘⇧X — alle vorbereiteten Änderungen verwerfen (mit Bestätigung)

Aus einer Rasterauswahl kannst du Löschungen vorbereiten, ohne den Editor zu öffnen:

• ⌘⌫ — eine Löschung der ausgewählten Zeilen vorbereiten
• ⌘⇧⌫ — die ausgewählten Zeilen löschen & committen

Konflikte

Weil Commits optimistisches Locking nutzen, wird eine Änderung, die jemand anderes committet hat, nachdem du deine vorbereitet hast, erkannt statt stillschweigend überschrieben. Die Karte zeigt ein Inline-Banner:

• Drift — das entfernte Item hat sich unter dir verändert. Auf entfernten Stand rebasen aktualisiert die Baseline, sodass du erneut prüfen kannst, oder Abbrechen der Änderung.
• Entfernt gelöscht — das Item existiert nicht mehr. Brich die Änderung ab.
• Netzwerk nicht verfügbar — der Commit konnte DynamoDB nicht erreichen. Erneut versuchen oder abbrechen.

Ein Commit hält beim ersten fehlgeschlagenen Batch an — frühere erfolgreiche Batches bleiben geschrieben, der Rest wird nicht versucht, und die Fehler erscheinen als zu lösende Konflikte.

Was Commits blockiert

Manche Zustände sind schreibgeschützt und können vorbereiten, aber nicht committen — vor allem eine abgelaufene oder schreibgeschützte Lizenz. Das Vorbereiten funktioniert weiterhin; das Committen wird wieder freigeschaltet, sobald die App in einen aktiven Zustand zurückgekehrt ist.