Bulk operations (safe bulk)
Bulk set, transform or delete with a dry-run preview, exact counts and abort.
The bulk panel applies one action — set, transform, or delete — to every item matching a scope, with an exact count, a before/after preview, and an abort button, so large changes are deliberate rather than surprising.
The three steps
The panel walks you through scope, action, and a dry-run before anything runs.
1. Scope
The top of the panel is the same condition builder as the grid’s Busca search. Add conditions and Tablyne routes them to a query (PK pinned) or a scan, exactly as it does for browsing — so a bulk runs over precisely the items your search would return.
The scope line summarizes what’s targeted, e.g. QUERY pk = USER#42 · sk begins_with ORDER#. If you leave it empty, it warns clearly that the action affects the whole table.
2. Action
| Action | What it does |
|---|---|
| Set | Assign one or more attribute = value pairs on every matched item (type auto/S/N/BOOL, auto-inferred from your loaded data) |
| Transform | Run a per-item JavaScript function (item in scope, return the new item) — the same model as the REPL |
| Delete | Remove every matched item |
For transform, write an expression or script returning the updated item:
({ ...item, total: item.price * item.qty })A transform that returns the unchanged item (or null) is skipped — only genuinely changed items are written. If you have an AI provider configured, you can describe the change in natural language and have it draft the transform code; see /docs/ai-transform/.
3. Dry-run preview
Click preview (dry-run). Tablyne:
- Counts the exact number of matched items server-side (a scan/query with your filter, paged in full — not an estimate).
- Shows a sample of up to 12 items with before → after for set/transform, or removed for delete, so you can verify the change is doing what you intend.
The affected count appears on the scope line, e.g. · 1,240 affected.
Executing
Click execute. A confirmation dialog spells out the action, the count and the scope, and requires you to confirm (it’s marked destructive). Then:
- Delete runs server-side: a filtered scan finds matching keys and removes them via batched
DeleteItem(25 per batch). - Set / transform stream through the matched items in pages of 500: each item is set/transformed in memory, then written back via
BatchWriteItemin chunks of 25, with unprocessed-item retry.
A live progress line reports written / scanned / skipped as it goes, and an abort button stops the loop between pages. When it finishes, you get an exact processed count and the grid refreshes.
Idempotency matters
Transform runs over the live result, page by page. Make your transform idempotent — running it twice should be safe — because a transform that depends on its own prior output (e.g. count + 1 without a guard) can compound if re-run. The panel flags this in the transform editor.
Limitations to keep in mind
- Set and transform write the whole item back (
PutItem, last-write-wins) — there are no partialUpdateItemexpressions, and a concurrent change by someone else can be overwritten. - A scope with no conditions targets the entire table — the panel warns, but it’s on you to confirm.
- Transform/set is not transactional: it’s many batched writes, so an abort or error mid-run leaves the already-written items changed (progress shows how far it got).
- Counts and deletes against the whole table consume read (and write) capacity proportional to table size, since filters apply after the read — see /learn/query-vs-scan/.