Per [sneak/pixa PR #36](https://git.eeqj.de/sneak/pixa/pulls/36), the standard migrations pattern should be:
1. **`schema_migrations` table DDL lives in `000.sql`** (not inline Go code)
2. **`version` column is `INTEGER PRIMARY KEY`** (not TEXT)
3. **`000.sql` is self-contained** — contains both `CREATE TABLE IF NOT EXISTS` and `INSERT OR IGNORE INTO schema_migrations (version) VALUES (0)`
4. **Go code does zero INSERTs** for the bootstrap — just reads and executes `000.sql`
This repo currently creates the migrations table inline in Go code. It should be moved to follow the pixa pattern.
Reference implementation: [sneak/pixa `000.sql`](https://git.eeqj.de/sneak/pixa/src/branch/main/internal/database/schema/000.sql) and [`database.go`](https://git.eeqj.de/sneak/pixa/src/branch/main/internal/database/database.go).
Blocking premise mismatch found while starting this: webhooker does not currently create a schema_migrations table in Go code. There is no schema_migrations table anywhere (not in the code, not in git history) and no .sql migration files. Schema is managed entirely via GORM AutoMigrate — internal/database/models.goMigrate() for the main DB, and per-webhook event DBs in internal/database/webhook_db_manager.go. So there is nothing to "move" into 000.sql.
Adopting the pixa numbered-SQL pattern here would be a from-scratch architecture change (replace AutoMigrate with hand-written SQL DDL for ~9 models across two DB tiers, plus an apply loop and embed) — much larger than #56 as written, and not behavior-preserving. The alternative, a vestigial schema_migrations table alongside AutoMigrate, tracks nothing real.
Your call: (a) close#56 as not-applicable and keep AutoMigrate, or (b) commit to the full SQL-migration conversion as a larger tracked task. Recommend (a) unless you specifically want SQL-file migrations. Assigning to you.
Blocking premise mismatch found while starting this: webhooker does not currently create a `schema_migrations` table in Go code. There is no `schema_migrations` table anywhere (not in the code, not in git history) and no `.sql` migration files. Schema is managed entirely via GORM `AutoMigrate` — `internal/database/models.go` `Migrate()` for the main DB, and per-webhook event DBs in `internal/database/webhook_db_manager.go`. So there is nothing to "move" into `000.sql`.
Adopting the pixa numbered-SQL pattern here would be a from-scratch architecture change (replace `AutoMigrate` with hand-written SQL DDL for ~9 models across two DB tiers, plus an apply loop and embed) — much larger than #56 as written, and not behavior-preserving. The alternative, a vestigial `schema_migrations` table alongside `AutoMigrate`, tracks nothing real.
Your call: (a) close #56 as not-applicable and keep `AutoMigrate`, or (b) commit to the full SQL-migration conversion as a larger tracked task. Recommend (a) unless you specifically want SQL-file migrations. Assigning to you.
sneak
was assigned by clawbot2026-07-26 20:44:35 +02:00
REPO_POLICIES.md already decides this, so it comes off your list. The schema lives in SQL files embedded in the binary under internal/db/migrations/: 000_migration.sql creates only the tracking table, and 001_schema.sql holds the full schema, edited directly before 1.0. The earlier recommendation to close this missed that rule.
webhooker builds its schema with GORM AutoMigrate in three places: the main database, the per-webhook event databases and the archive files. The fleet builds the conversion: one 000_migration.sql and one 001_schema.sql per kind of database file, applied when the file is opened, in place of AutoMigrate. GORM stays for queries. This also drops the parent tables that AutoMigrate adds to every event database, and the sweep that removes them. Reassigned to clawbot.
Model: opus-5-5
`REPO_POLICIES.md` already decides this, so it comes off your list. The schema lives in SQL files embedded in the binary under `internal/db/migrations/`: `000_migration.sql` creates only the tracking table, and `001_schema.sql` holds the full schema, edited directly before 1.0. The earlier recommendation to close this missed that rule.
webhooker builds its schema with GORM `AutoMigrate` in three places: the main database, the per-webhook event databases and the archive files. The fleet builds the conversion: one `000_migration.sql` and one `001_schema.sql` per kind of database file, applied when the file is opened, in place of `AutoMigrate`. GORM stays for queries. This also drops the parent tables that `AutoMigrate` adds to every event database, and the sweep that removes them. Reassigned to clawbot.
Model: opus-5-5
sneak
was unassigned by clawbot2026-10-13 03:15:16 +02:00
clawbot
self-assigned this 2026-10-13 03:15:16 +02:00
Built in #519. Each kind of database file has 000_migration.sql and 001_schema.sql under internal/db/migrations/ (main/, events/, archive/), applied in one transaction when the file is opened, in place of AutoMigrate. Event databases no longer carry copies of the main database's tables, and the sweep that cleaned them is gone.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/webhooker/pulls/519. Each kind of database file has `000_migration.sql` and `001_schema.sql` under `internal/db/migrations/` (`main/`, `events/`, `archive/`), applied in one transaction when the file is opened, in place of `AutoMigrate`. Event databases no longer carry copies of the main database's tables, and the sweep that cleaned them is gone.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Per sneak/pixa PR #36, the standard migrations pattern should be:
schema_migrationstable DDL lives in000.sql(not inline Go code)versioncolumn isINTEGER PRIMARY KEY(not TEXT)000.sqlis self-contained — contains bothCREATE TABLE IF NOT EXISTSandINSERT OR IGNORE INTO schema_migrations (version) VALUES (0)000.sqlThis repo currently creates the migrations table inline in Go code. It should be moved to follow the pixa pattern.
Reference implementation: sneak/pixa
000.sqlanddatabase.go.Blocking premise mismatch found while starting this: webhooker does not currently create a
schema_migrationstable in Go code. There is noschema_migrationstable anywhere (not in the code, not in git history) and no.sqlmigration files. Schema is managed entirely via GORMAutoMigrate—internal/database/models.goMigrate()for the main DB, and per-webhook event DBs ininternal/database/webhook_db_manager.go. So there is nothing to "move" into000.sql.Adopting the pixa numbered-SQL pattern here would be a from-scratch architecture change (replace
AutoMigratewith hand-written SQL DDL for ~9 models across two DB tiers, plus an apply loop and embed) — much larger than #56 as written, and not behavior-preserving. The alternative, a vestigialschema_migrationstable alongsideAutoMigrate, tracks nothing real.Your call: (a) close #56 as not-applicable and keep
AutoMigrate, or (b) commit to the full SQL-migration conversion as a larger tracked task. Recommend (a) unless you specifically want SQL-file migrations. Assigning to you.REPO_POLICIES.mdalready decides this, so it comes off your list. The schema lives in SQL files embedded in the binary underinternal/db/migrations/:000_migration.sqlcreates only the tracking table, and001_schema.sqlholds the full schema, edited directly before 1.0. The earlier recommendation to close this missed that rule.webhooker builds its schema with GORM
AutoMigratein three places: the main database, the per-webhook event databases and the archive files. The fleet builds the conversion: one000_migration.sqland one001_schema.sqlper kind of database file, applied when the file is opened, in place ofAutoMigrate. GORM stays for queries. This also drops the parent tables thatAutoMigrateadds to every event database, and the sweep that removes them. Reassigned to clawbot.Model: opus-5-5
Built in #519. Each kind of database file has
000_migration.sqland001_schema.sqlunderinternal/db/migrations/(main/,events/,archive/), applied in one transaction when the file is opened, in place ofAutoMigrate. Event databases no longer carry copies of the main database's tables, and the sweep that cleaned them is gone.Model: opus-5-5