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).
This issue does not apply to dnswatcher. The repo uses JSON file-based state persistence (internal/state/state.go → DATA_DIR/state.json), not SQLite. There are:
No .sql files anywhere in the repo
No database package
No SQLite dependency in go.mod
No migrations infrastructure of any kind
No schema_migrations table creation (inline or otherwise)
The issue description states "This repo currently creates the migrations table inline in Go code" — this is factually incorrect. dnswatcher has never used SQLite.
The referenced pattern from sneak/pixa PR #36 applies to repos with existing SQLite migration infrastructure. dnswatcher has none.
Recommendation: close this issue as not applicable, or re-scope it if there's a planned migration from JSON state to SQLite (which would be a much larger piece of work than what's described here).
This issue does not apply to dnswatcher. The repo uses **JSON file-based state persistence** (`internal/state/state.go` → `DATA_DIR/state.json`), not SQLite. There are:
- No `.sql` files anywhere in the repo
- No `database` package
- No SQLite dependency in `go.mod`
- No migrations infrastructure of any kind
- No `schema_migrations` table creation (inline or otherwise)
The issue description states "This repo currently creates the migrations table inline in Go code" — this is factually incorrect. dnswatcher has never used SQLite.
The referenced pattern from [sneak/pixa PR #36](https://git.eeqj.de/sneak/pixa/pulls/36) applies to repos with existing SQLite migration infrastructure. dnswatcher has none.
Recommendation: close this issue as not applicable, or re-scope it if there's a planned migration from JSON state to SQLite (which would be a much larger piece of work than what's described here).
clawbot
removed their assignment 2026-03-25 02:34:26 +01:00
sneak
was assigned by clawbot2026-03-25 02:34:26 +01: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.This issue does not apply to dnswatcher. The repo uses JSON file-based state persistence (
internal/state/state.go→DATA_DIR/state.json), not SQLite. There are:.sqlfiles anywhere in the repodatabasepackagego.modschema_migrationstable creation (inline or otherwise)The issue description states "This repo currently creates the migrations table inline in Go code" — this is factually incorrect. dnswatcher has never used SQLite.
The referenced pattern from sneak/pixa PR #36 applies to repos with existing SQLite migration infrastructure. dnswatcher has none.
Recommendation: close this issue as not applicable, or re-scope it if there's a planned migration from JSON state to SQLite (which would be a much larger piece of work than what's described here).