Staging & Commit
Bearbeitungen, Erstellungen und vorgemerkte Löschungen von Items laufen über einen Staging-Bereich, bevor sie DynamoDB erreichen. Stell ihn dir wie eine Git-Staging-Area mit Sicherheitsriegel vor: Änderungen sammeln sich als prüfbare Diffs und gehen erst dann als hinaus, wenn du committest.
Zwei Wege lassen das Staging bewusst aus: Schreibanweisungen in PartiQL laufen mit einer Warnung direkt gegen deine Tabelle, und ⌘⇧⌫ löscht die ausgewählten Zeilen und committet in einem Schritt.
So funktioniert es
Jede Tabelle hat ihren eigenen Staging-Bereich, den sich alle Ansichten dieser Tabelle teilen. Wenn du eine Item-Bearbeitung speicherst, eine Zeile anlegst oder eine löschst, landet die Änderung als Diff pro Attribut im Panel – hinzugefügte, entfernte und geänderte Attribute stehen nebeneinander. Betroffene Zeilen im Grid werden nach Operation eingefärbt:
- grün – ein neues Item (anlegen)
- orange – eine Änderung (geänderte Zellen hervorgehoben)
- rot – eine Löschung (durchgestrichen)
Öffne dieselbe Tabelle in zwei Tabs, und beide zeigen dieselben offenen Änderungen; schließt du einen Tab und öffnest ihn wieder, ist das Staging immer noch da. Einen Tab zu schließen verwirft nie deine vorgemerkten Änderungen.
Das Panel schaltest du mit ⌘⇧D um. An seiner Kante ziehst du es größer oder kleiner.
Änderungen prüfen
Jede Diff-Karte zeigt genau, was sich ändern wird:
- Skalare erscheinen als alt → neu mit roter und grüner Hervorhebung.
- Lange Strings zeigen inline ein Diff auf Wortebene.
- Maps und Listen erscheinen als formatiertes JSON (in v1 immer als ganzes Attribut).
Mit Reject pro Attribut setzt du auf einer Karte ein einzelnes Attribut auf seinen ursprünglichen Wert zurück. Lehnst du jedes Attribut ab, verschwindet die ganze Änderung.
Committen
Committe, um deine vorgemerkten Änderungen nach DynamoDB zu schreiben:
- Commit N schickt jede vorgemerkte Änderung dieser Tabelle hinaus – über alle ihre Tabs hinweg.
- Commit just this schickt eine einzelne Änderung von ihrer Karte aus hinaus.
Commits gehen als TransactWriteItems-Batches mit Bedingungen für
optimistisches Sperren hinaus: Eine Änderung gelingt nur, wenn die Attribute noch
die Werte tragen, von denen du ausgegangen bist, ein Anlegen nur, wenn das Item
noch nicht existiert, und ein Löschen nur, wenn das Item noch da ist. Der
Expression-Builder auf dieser Website baut
dieselben Formen für UpdateExpression und ConditionExpression, falls du sie dir
außerhalb des Staging-Panels ansehen willst. Große Stapel werden automatisch
zerlegt, damit sie innerhalb von DynamoDBs Transaktionsgrenzen bleiben.
Die Tastenkürzel zum Speichern aus dem Editor gelten auch hier:
- ⌘S – ins Staging legen (kein Commit)
- ⌘⇧S – speichern und committen
- ⌘⇧X – alle vorgemerkten Änderungen verwerfen (mit Rückfrage)
Aus einer Auswahl im Grid heraus kannst du Löschungen vormerken, ohne den Editor zu öffnen:
- ⌘⌫ – eine Löschung der ausgewählten Zeilen vormerken
- ⌘⇧⌫ – die ausgewählten Zeilen löschen und committen
Konflikte
Weil Commits optimistisches Sperren verwenden, wird eine Änderung, die jemand anders committet hat, nachdem du deine vorgemerkt hattest, erkannt statt stillschweigend überschrieben. Die Karte zeigt dann ein Banner inline:
- Drift – das Item auf der Gegenseite hat sich unter dir verändert. Rebase onto remote frischt die Ausgangsbasis auf, damit du erneut prüfen kannst, oder du brichst die Änderung mit Abort ab.
- Remote deleted – das Item gibt es nicht mehr. Brich die Änderung ab.
- Network unavailable – der Commit hat DynamoDB nicht erreicht. Retry oder abbrechen.
Ein Commit hält beim ersten fehlgeschlagenen Batch an – vorher erfolgreiche Batches bleiben geschrieben, der Rest wird gar nicht erst versucht, und die Fehlschläge tauchen als Konflikte zum Auflösen auf.
Was Commits blockiert
Bearbeiten, Vormerken und Committen brauchen alle eine Lizenz im Status Trialing oder Active. Ein Zustand blockiert den ganzen Weg, nicht nur den Commit – er wird wieder frei, sobald die App zurück in einem aktiven Zustand ist.