tables

In the site’s settings.json, a table owns everything about its data: the schema (col), the read channels (views) and the write channels (forms). Where any of it is DISPLAYED is bound elsewhere — public routes and the admin menu. Tables are auto-migrated at startup.

col key	description
name	SQL identifier: letters, digits, underscore
type	id \| int \| text \| real \| bool \| blob; at most one id column per table
index	true — SQL index; required for columns used in filter_by

The (shortened) table behind these articles:

"docs": {
  "db": "main",
  "col": [
    { "name": "id", "type": "id" },
    { "name": "grp", "type": "text", "index": true },
    { "name": "title", "type": "text" },
    { "name": "published", "type": "bool", "index": true }
  ],
  "views": {
    "doc_list":  { "select": ["id", "grp", "title"], "fixed_filter": { "published": 1 },
                   "filter_by": ["grp"], "limit": 50 },
    "doc_admin": { "select": ["id", "grp", "title", "published"], "limit": 50 }
  },
  "forms": {
    "doc_edit": { "access": "user",
                  "fields": [ { "name": "title", "widget": "text", "required": true } ] }
  }
}

View and form names are global: routes and the admin menu reference them by bare name, so two tables cannot both declare a doc_edit. Details: views, routes (forms are described there too).