Table types
Every table in Ronja is one of four kinds, shown as a chip on the table page. The kind determines where the data comes from, how it rebuilds, and whether you can edit it. Background: Tables.
| Kind | What it is (product description) | Source | Rebuild behavior | Editability |
|---|---|---|---|---|
| Foundation | “Cleans and standardizes raw source data into a reliable base layer.” | Raw source data, standardized by Ronja | No per-table build controls — rebuilt by Ronja, not by you | Not code-editable — no Code tab. Name, description, and dictionary metadata are editable (by admins) |
| Integration | “Synced from an external connection — its shape mirrors the upstream system.” | An external connection | Refreshed by the connection’s sync schedule; admins can trigger a manual Refresh | Not code-editable — its shape mirrors the upstream system |
| Integration (file-fed) | “Updated by uploading files directly — its shape mirrors the uploaded data.” | Files pushed via the file push API or uploads | Rebuilds when you run Build after pushing files | Not code-editable — schema is auto-detected from the uploaded files |
| Derived | “Built from other tables as inputs with SQL.” | Other tables, via a SQL query | Rebuilds automatically whenever the data in one of its input tables changes — an input finishing a build, or rows written to or restored into a Dynamic table (a script sending several tables over the API can hold that back until it releases them, about 15–20 minutes at most); also on demand, or when produced by a workflow. Can go stale (“Out of sync”) until rebuilt | Fully editable through drafts: tabs Data · Columns · Query (SQL) or Code · Checks · Details, plus Activity on live tables |
| Dynamic | “Written to directly by agents as they run.” | Agents writing rows during runs — or your own app or scheduled script pushing rows or a Parquet file in with the row push API | Updated live by each write; no separate build step. Each write or restore also rebuilds the Derived tables built from it; clearing it starts the same rebuild, which fails — a clear removes its data and its column types, not just its rows, so there is nothing to build from — so they keep their earlier data. A Dynamic table can be queried as soon as it is created, and returns no rows until something writes to it | Not code-editable; keeps version snapshots that can be restored directly |
Every kind has a Checks tab — health checks are about a table’s data, not its definition, so they apply just as much to a Foundation or Integration table as to a Derived one. The Query or Code tab is the one that is Derived-only.
Build status
Section titled “Build status”A table’s build status is shown as a dot + label on its page and in lists:
| Status | Meaning |
|---|---|
ready |
Built and queryable |
building |
A build is in progress (“Building table…”) |
pending |
Waiting to build |
invalidated |
Inputs changed — stale until rebuilt (banner: “Out of sync — showing data from last successful build”) |
build_failed |
The last build errored (banner: “Build failed”, expandable error, admin rebuild) |
A table normally lands in build_failed only when it has never built successfully — a table that has data keeps serving it and shows how old that data is and since when its updates have failed instead (marked Not updating in lists; see When a table stops updating). There are two exceptions, both builds that can never succeed again. In each, the table is flagged build_failed even though its last good data is still queryable, so a permanently broken rebuild isn’t mistaken for an ordinary stale one:
- One of a Derived table’s input tables is gone. Any table listed among its inputs that was deleted for good stops it, even one its recipe no longer reads; so does an input in the trash that it reads. Restore the input from Trash if it is still there, or edit the table’s recipe and its inputs together to replace or remove it. See Builds.
- The table reads itself through its inputs, directly or through other tables. The error says the table “would read itself through its inputs” and names the loop. A rebuild never clears it: remove an input that is part of the loop — from this table or another table on it — and commit the change. See Builds.
Editing rules worth knowing
Section titled “Editing rules worth knowing”- One draft per person per table. Creating a second draft fails with “A draft already exists for this table”.
- Shared tables are review-gated. A non-admin’s edits become a draft (“Draft pending review”); an Admin reviews the SQL diff and commits. Admins commit their own drafts directly.
- Version restore never overwrites live silently. Restoring a Derived table’s old version creates a new draft to review; Dynamic table snapshots restore immediately.
- Tables ≤ 1 MB preview in full (searchable grid); larger tables show a capped preview.