Staging & commit
Every edit in DynoTable goes through a staging area before it touches DynamoDB. Think of it as a git staging area with a safety latch: edits, creates, and deletes accumulate as reviewable diffs, then ship as only when you commit.
Nothing is written to your table until you say so.
How it works
Each table has its own staging area, shared across every view of that table. When you save an item edit, create a row, or delete one, the change lands in the panel as a per-attribute diff — added, removed, and changed attributes shown side by side. Affected rows in the grid are tinted by operation:
- green — a new item (create)
- orange — an update (changed cells highlighted)
- red — a deletion (struck through)
Open the same table in two tabs and they show the same pending changes; close and reopen a tab and the stage is still there. Closing a tab never discards your staged changes.
Toggle the panel with ⌘⇧D. Drag its edge to resize it.
Reviewing changes
Each diff card shows exactly what will change:
- Scalars render old → new with red/green highlighting.
- Long strings show an inline word-level diff.
- Maps and Lists render as pretty-printed JSON (whole-attribute in v1).
Use a card's per-attribute Reject to drop a single attribute back to its original value. Reject every attribute and the whole change is discarded.
Committing
Commit to write your staged changes to DynamoDB:
- Commit N ships every staged change for that table — across all its tabs.
- Commit just this ships a single change from its card.
Commits go out as TransactWriteItems batches with optimistic-locking
conditions: an update only succeeds if the attributes still hold the values you
started from, a create only succeeds if the item doesn't already exist, and a
delete only succeeds if the item is still there. Large stages are automatically
chunked to stay within DynamoDB's transaction limits.
The save chords from the editor apply here too:
- ⌘S — stage (no commit)
- ⌘⇧S — save & commit
- ⌘⇧X — discard all staged changes (with confirmation)
From a grid selection you can stage deletes without opening the editor:
- ⌘⌫ — stage a delete of the selected rows
- ⌘⇧⌫ — delete & commit the selected rows
Conflicts
Because commits use optimistic locking, a change committed by someone else after you staged yours is detected rather than silently overwritten. The card shows an inline banner:
- Drift — the remote item changed underneath you. Rebase onto remote refreshes the baseline so you can re-review, or Abort the change.
- Remote deleted — the item no longer exists. Abort the change.
- Network unavailable — the commit couldn't reach DynamoDB. Retry or abort.
A commit halts on the first failed batch — earlier successful batches stay written, the rest are not attempted, and the failures surface as conflicts to resolve.
What blocks commits
Some states are and can stage but not commit — most notably an expired or read-only licence. Staging still works; commit unlocks again once the app is back to an active state.