Staged edits & committing
Edits, deletes and new items are staged and committed together (Ctrl+S) or discarded.
Tablyne uses an IDE-style staging model for writes: changes you make in the grid or item editor accumulate locally and are committed together with Ctrl+S, or thrown away — nothing touches DynamoDB until you say so.
Why staging
Most DynamoDB GUIs write every cell edit straight to the table, which makes a fat-fingered change instantly live and irreversible. Tablyne instead batches your pending work so you can review it, keep editing, and commit (or discard) as one deliberate action — the same mental model as editing files and saving in an editor.
The three buckets
Pending changes are tracked in three buckets, keyed by a stable identifier derived from each item’s PK (and SK, if the table has one):
| Bucket | What it holds | Created by |
|---|---|---|
| Edits | The full updated item, latest value wins per row | Editing a cell, or saving an existing item in the editor |
| Deletes | Keys marked for deletion (with key attributes snapshotted) | Delete, the 🗑 button, or delete item in the context menu |
| Adds | Brand-new items with no server identity yet | ＋ Row, or saving a new item in the editor |
A few consistency rules apply automatically:
- Delete wins over edit — marking a row for deletion drops any staged edit for the same key.
- New rows live in the view — staged adds appear prepended to the grid (highlighted) until commit.
- Editing a staged add edits it in place — it never becomes a separate edit entry.
- Toggling delete — pressing delete on an already-staged-deleted row un-stages it.
The pending-changes bar
As soon as anything is staged, a bar appears above the grid:
● 3 pendências 1 editar · 1 excluir · 1 novos [ salvar (Ctrl+S) ] [ descartar ]Cells are color-coded so you can see the staged state at a glance: added rows and edited cells are tinted, and deleted rows are dimmed with a ~ prefix and frozen (not re-editable until un-deleted).
Committing
Press Ctrl+S (or click salvar) to commit. The active tab is the only one that listens for the shortcut, so committing always targets the table you’re looking at. On commit, Tablyne:
- Sends all adds and edits as
PutItems, batched viaBatchWriteItemin chunks of 25 (with automatic retry of anyUnprocessedItems). - Issues a
DeleteItemfor each staged delete, using the key attributes snapshotted when the row was staged — so the commit never has to recover a row that may have been paged out. - Clears the staging buckets and refreshes the affected data.
If a commit fails, the error is shown in the bar and your staged changes are kept so you can retry.
Discarding
Click descartar to drop all pending changes and refresh from DynamoDB. There is no per-change undo within a session — discard is all-or-nothing.
Cross-tab safety
Each table tab publishes whether it has uncommitted changes. If you switch the active connection or profile while a tab is dirty, Tablyne can warn you before discarding those edits across tabs. See /docs/workspace-tabs/.
Limitations to keep in mind
- A commit is a whole-item
PutItem, not a partialUpdateItem. It replaces the entire item and is last-write-wins — if someone else changed the item after you loaded it, your commit overwrites their change. There is no conditional/optimistic check. - Staging is in-memory and per session — closing the tab or app, or discarding, loses uncommitted work. It is not persisted to disk.
- A renamed key is committed as a delete-plus-add, not an atomic operation; the two writes are not transactional.