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, typically via SQL or Python.” | Other tables, via SQL or Python | Rebuilt on demand or when produced by a workflow; can go stale (“Out of sync”) until rebuilt | Fully editable through drafts: tabs Result · Catalog · Code |
| 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 | Not code-editable; keeps version snapshots that can be restored directly |
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 “Out of sync” instead. The exception is a build that can never succeed again: if one of a Derived table’s input tables has been deleted, 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. Restore the input from Trash, or edit the table’s inputs, to clear it.
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.