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
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.