clawbot
d5c3d4d55f
All checks were successful
Check / check (push) Successful in 5s
Closes #171 Refactors the migration system to follow the [pixa pattern](sneak/pixa#36): ## Changes ### New file: `internal/database/migrations/000.sql` - Bootstrap migration that creates `schema_migrations` with `version INTEGER PRIMARY KEY` - Self-contained: includes both `CREATE TABLE IF NOT EXISTS` and `INSERT OR IGNORE INTO schema_migrations (version) VALUES (0)` ### Refactored: `internal/database/migrations.go` - **Go code no longer creates the migrations table inline** — it reads and executes `000.sql` as a bootstrap step before the normal migration loop - **`ParseMigrationVersion(filename)`** — exported function that extracts integer version from filenames like `001_initial.sql` → `1` - **`ApplyMigrations(ctx, db, log)`** — exported function for tests to apply schema without full fx lifecycle - **`bootstrapMigrationsTable`** — checks if table exists; if missing, runs `000.sql`; if present, checks for legacy format - **`convertLegacyMigrations`** — one-time conversion for existing databases that stored versions as TEXT filenames (e.g. `"001_initial.sql"`) to INTEGER versions (e.g. `1`) - **Transaction-wrapped migration application** — each migration runs in a transaction for atomicity - Sentinel error `ErrInvalidMigrationFilename` for static error wrapping ### New file: `internal/database/migrations_test.go` - `TestParseMigrationVersion` — valid/invalid filename parsing - `TestApplyMigrationsFreshDatabase` — verifies bootstrap creates table, all migrations apply, application tables exist - `TestApplyMigrationsIdempotent` — double-apply is a no-op - `TestApplyMigrationsLegacyConversion` — simulates old TEXT-based table with filename entries, verifies conversion to integer format ## Backward Compatibility Existing databases with the old TEXT-based `schema_migrations` table are automatically converted on first run. The conversion: 1. Detects legacy entries (versions containing `_`) 2. Parses integer version from each legacy filename 3. Drops the old table 4. Creates the new INTEGER-based table via `000.sql` 5. Re-inserts all parsed integer versions All existing migrations (001-007) continue to work unchanged. Co-authored-by: user <user@Mac.lan guest wan> Co-authored-by: clawbot <clawbot@sneak.berlin> Reviewed-on: #172 Co-authored-by: clawbot <clawbot@noreply.example.org> Co-committed-by: clawbot <clawbot@noreply.example.org>
6.0 KiB
6.0 KiB