Database schema, migrations and the grid with writes
The database schema is read onto the canvas, compared with it, and the differences become a migration. Data is edited in a grid that writes back to the database.
Schema from the database
"Data → 🗄 Schema from DB…" reads tables, views, columns and foreign keys by connection name and places them as a group "DB: name". A local connection profile is executed by the app itself, agent:<agent>/<name> by the server through the agent, sqlite:<path> is a file in the workspace sandbox. Reading again updates the group in place, arranged tables stay. A field keeps the exact database type. Indexes, view bodies and CHECK constraints are read into table fields.
Compare and migrate
"Compare" shows how the canvas differs from the database: by tables and columns, with "≠ DB" and "not in DB" badges on nodes. "Refresh" re-reads the schema. "Migration from differences" places a group of executable nodes: "▶ Apply" with a chain of sql-exec actions, one step per statement, and "↩ Rollback" next to it. Nothing is applied by itself. Dropping what is absent on the canvas enters the migration only with a checkbox. Renaming a column becomes CHANGE COLUMN, not drop and create. The "log in DB" checkbox keeps a myetern_migrations table. An applied group receives a dated mark.
Right-click a table → "🗄 SQL: CREATE…" dumps the selected tables in dependency order as a "Text" node or as a group ready to apply.
The grid with writes
A mysql or pgsql source with SELECT … FROM table, connected by an edge to a "Data table", gives a grid where every cell is editable. An edit becomes UPDATE … WHERE key = …, the key is id or the "DB: key" field. Before executing, a question shows the SQL text and a button "Apply and autosave", for bulk edits there is a node toggle and a global flag in the Edit menu.
| Action | What it does |
|---|---|
| + Row | adds rows locally, "INSERT new" sends them with one question, the auto-increment key arrives straight into the row |
| ⎘ Rows from clipboard… | turns a table from the clipboard into new rows |
| − Rows | deletes the selected rows with one DELETE by key |
| ↶ undo | reverts the last action with the opposite SQL, this is a data undo, not a canvas one |
| ⧉ collect | edits accumulate, "Apply all" sends the batch in one transaction |
| ⏺ record to migration | edits accumulate as forward and backward SQL and leave as a "Data migration" group |
Grid shortcuts use Alt: Alt+Z undo, Alt+B collect, Alt+A apply all, Alt+M record to migration, Alt+N row, Alt+V rows from clipboard.
Columns and keys from the grid
"+ Column (ALTER)…" adds a column with a type by kind. In the column menu: rename in DB, drop column, set the type by kind, index, unique index, primary key. The same question, the same batch, the same undo. The full schema with foreign keys and views is still kept by "Table" and "Field" nodes together with the migration from differences.
Permissions
A local profile is executed by the app. Connections through the agent and the SQLite sandbox are executed by the server and need write access in the room and the cap.sql capability.