DynoTable

Editing items

DynoTable edits items as JSON in a real code editor — autocomplete, formatting, and inline validation. Saving stages the change for review by default; a second chord commits it. Both need an active license.

Open an item from the grid to edit it, or press ⌘N to create a new one. A new item is pre-populated with the table's key attributes; fill in the rest.

DynoTable's DynamoDB item editor: the JSON buffer, the Plain-JSON / DynamoDB-JSON mode toggle, and the save controls.
DynoTable's DynamoDB item editor: the JSON buffer, the Plain-JSON / DynamoDB-JSON mode toggle, and the save controls.

JSON modes

A toggle in the editor header switches how the item is represented. Switching between Plain and DynamoDB JSON round-trips Strings, Numbers, Booleans, Null, Maps, Lists, and Sets — within the two limits at the end of this page.

  • Plain — primitives stay plain ("count": 3, not {"N": "3"}). Sets use a compact one-key sentinel: {"SS": [...]} for string sets, {"NS": [...]} for number sets, {"BS": [...]} for binary sets. The easiest mode to read and edit by hand.
  • DynamoDB JSON — the canonical AWS wire form, where every value is type-wrapped. Use it when you're pasting DynamoDB-JSON from elsewhere.
  • Document — the item as a form, one control per attribute, instead of JSON. Editable; see Document view below.
  • Flow — a read-only graph of the parsed item (Maps, Lists, and Sets as nodes). Useful for understanding the shape of a deeply nested record. Edits still happen in the Plain / DynamoDB buffer underneath.

Press ⌘⇧M in the editor to cycle modes. A ? next to the toggle shows a side-by-side example of each format.

Document view

Document view renders the item as a form — one labelled control per attribute, chosen from the value it holds. It's available on every table. On a table with a vector index whose items carry prose it's also the default — those records are articles, and a JSON editor is the wrong tool for an article.

  • Text — a box that grows with the content, so a paragraph stays a paragraph instead of one long line with \n escapes in it. It offers autocomplete from the values that column already holds in the local index, the same source the filter pills read.
  • Numbers and booleans — a number field and a switch.
  • Dates — the raw value in a text field with a calendar picker on the end of it (plus a time field when the value carries a time), and the decoded reading under it. What you pick is written back in the encoding the attribute already used: epoch seconds stay epoch seconds, an ISO string stays an ISO string.
  • Sets and lists of simple values — one chip per member, added and removed individually. The container and the member type are kept, so a number set stays a number set.
  • Keys — a single-line field, and editable, as they are in the JSON views. A new item is nothing but its key scaffold, so a read-only key would make creating one here impossible.

Maps, mixed lists, and binary are read-only here — no single control edits them honestly. Switch to Plain or DynamoDB JSON for those. An embedding is shown as a one-line summary instead of the numbers themselves.

Edits land in the same buffer the JSON views show, and save with the same chords.

An order open in DynoTable's Document view: one labelled control per attribute instead of JSON — a number field for the amount, text boxes for the product id and status, a date field with a calendar picker and the decoded reading under it, and chips for the item list. The two key fields carry their partition and sort marks.
An order open in DynoTable's Document view: one labelled control per attribute instead of JSON — a number field for the amount, text boxes for the product id and status, a date field with a calendar picker and the decoded reading under it, and chips for the item list. The two key fields carry their partition and sort marks.

Validation

The editor validates as you type and surfaces problems inline:

  • Malformed JSON and schema violations show as editor diagnostics.
  • Key attributes are checked so you can't save an item missing its partition/sort key.
  • Press ⌘⇧F to reformat the buffer.

If a parse error blocks a mode switch, the toggle snaps back and the error stays visible — your buffer is never silently reformatted into something invalid.

Saving

Saving an item stages it — the change joins that table's staging area as a diff (shared across every view of the table) and is written to DynamoDB only when you commit. The two save chords:

  • ⌘S — stage the change (no commit). Safer; review it in the panel first.
  • ⌘⇧S — save and commit immediately.

Staging (or a clean commit) closes the editor. If a commit hits a write conflict or error, the editor stays open so you can rebase from the staging panel. To resume editing a staged change, reopen it from the staging panel's diff card.

Limitations

A few v1 edge cases are worth knowing:

  • Numbers larger than 2⁵³ lose precision in either JSON mode (a DynamoDB SDK boundary). For lossless large numbers, use the marshalled variant when you export.
  • Binary (B / BS) values edited in DynamoDB mode can round-trip to string types on save — edit binary in Plain mode.

Updated