logan
5ca6cad45a
A coding agent could develop this repo's Go packages and could not develop the application: every path to running YellowJacket ended in a blocking GTK window, so 265 bound methods, 46 events, 33 component directories and 13 stores had exactly one form of verification available — `tsc --noEmit`. The unlock is that `wails dev`'s dev server on :34115 serves the real frontend with the real generated bindings against the same Go backend a desktop window attaches to, so a plain Chromium under Xvfb gets a fully functional app. Four test tiers now exist, cheapest first: - `make ui-test` — 313 Vitest tests in a real browser in ~2 s, no app, no backend, no display. Works because `frontend/wailsjs/` is a pure passthrough to `window.go`/`window.runtime`, so faking just those two globals runs the real bindings and the real store code. - `make test` — services in-process, asserting on the payload the frontend would receive, via a new `events.Emit` wrapper. - `make dev-headless` + `playwright-cli` — the real app, driven interactively, with an event bridge on `window.__yjEvents` and a dev-only control surface at `/__test/`. - `make e2e` — 19 of those flows frozen as Playwright specs. `events.Emit(ctx, …)` replaces all 35 direct `runtime.EventsEmit` call sites: wails' `getEvents` `log.Fatalf`s on any context without its runtime, so those paths could not run under test and a background worker could take the app down. Four packages had each hand-rolled the same guard; nine more guarded on `ctx != nil`, which does not help. `TestNoDirectRuntimeEmits` fails the build on a new one. Fixtures are generated, not committed (`make testdata`), and seeds are built by *running the app* — never by hand-writing config and DB rows, which would be a second description of a valid YJ_HOME. `.gitea/workflows/ci.yml` is the first workflow here that tests anything; the other three only package, so `gitea_ci` reported only packaging jobs and misled anyone asking whether a push was healthy. Both jobs were prototyped to green in a bare ubuntu:24.04 container before the YAML was written, which immediately caught `make lint` linting three configurations that nothing builds: all three passes omitted `webkit2_41`, so wails resolved webkit2gtk-4.0 — which Arch still ships and Ubuntu 24.04 dropped. Operational instructions live in `.pi/skills/yellowjacket-dev/`, measured discoveries in `.planning/NOTES.md`, and architecture in `CLAUDE.md` — split by tense, not by topic, because a topical split gives every new fact two plausible homes. `make skill-check` fails a commit if the skill cites a make target that does not exist.
53 lines
2.3 KiB
Markdown
53 lines
2.3 KiB
Markdown
# Changing the database schema
|
|
|
|
The reasoning — why there are two files, what the old 48-step migration
|
|
chain got wrong, and when squashing is legitimate — is in `CLAUDE.md`
|
|
under *Backend packages → database*. Read it once. This is the
|
|
checklist.
|
|
|
|
A schema change needs **two** files, not one:
|
|
|
|
1. **`backend/database/sql/schemas/*.sql`** — `CREATE TABLE ... IF NOT
|
|
EXISTS`, the literal target shape, what sqlc reads and what a fresh
|
|
install gets verbatim. Add the new column **last** in the
|
|
`CREATE TABLE`.
|
|
2. **`backend/database/sql/migrations/NNNN_description.sql`** — the
|
|
`ALTER TABLE ... ADD COLUMN` (and any index on it) that gets an
|
|
existing database to the same shape. Schema files are a no-op against
|
|
a table that already exists, so without this an upgrade never gets
|
|
the column.
|
|
|
|
Then:
|
|
|
|
```bash
|
|
make generate # sqlc + templ
|
|
go test -tags webkit2_41 ./backend/database/ # migration + column-order tests
|
|
make test
|
|
```
|
|
|
|
Rebuild any seed you rely on (`make sandbox-seed NAME=default`) and
|
|
delete your own dev `YJ_HOME` if you want to see the fresh-install path
|
|
rather than the migrated one.
|
|
|
|
## The three ways this goes wrong
|
|
|
|
- **Column order must match between the two paths.** `ADD COLUMN`
|
|
always appends, so a migrated column declared anywhere but last in
|
|
`CREATE TABLE` leaves fresh and upgraded installs disagreeing on
|
|
order — and sqlc binds `SELECT *` positionally, so one of them
|
|
silently reads the wrong field.
|
|
`TestMigrations_ColumnOrderMatchesFreshInstall` is the regression test.
|
|
- **Do not put an index on a migrated column in `sql/schemas/`.**
|
|
Schema files run *before* migrations, against a database that may not
|
|
have the column yet, and the predicate fails. Declare the index in the
|
|
migration, after the `ALTER TABLE`.
|
|
- **Do not add a third description of the schema anywhere.** A
|
|
migration's `ADD COLUMN` failing with "duplicate column name" against
|
|
an already-current database is expected and tolerated, not an error to
|
|
route around.
|
|
|
|
New queries go in `backend/database/sql/queries/`; generated Go lands in
|
|
`backend/database/sql/sqlcgen/`, which is never edited by hand. Tests
|
|
use `database.NewTestDB(t)`, built by the same `applySchema` production
|
|
uses, so the two cannot diverge.
|