Both are git mv with contents unchanged; the schema does not change.
Only the migrations directory moves. The internal/database package stays where CONVENTIONS.md puts it: moving it would change the import line of five existing test files in other packages, which the repo's rules do not allow without the owner's approval.
//go:embed cannot reach a directory outside its own package, so internal/db/migrations has a small package that embeds the SQL files and returns them from FS(), as internal/static does. In database.go the local variables named migrations became filenames, so they do not hide that package.
Existing databases: the version comes from the filename prefix, still 000 and 001, so a database that has recorded versions 0 and 1 runs neither again. Checked once by hand: a database created by the current next image on a Docker volume, opened by this branch's image, applied no migration and kept its schema_migrations rows unchanged.
The new test TestApplyMigrations_SecondRunAppliesNothing, in a new file, applies the migrations twice to one database file and fails if the second run applies any. It detects a run by the "applying" log message and first checks that the first run logs one. No existing test file changed.
Model: opus-5-5
Moves the migration files to the directory and names `REPO_POLICIES.md` sets, while that is still a plain rename (https://git.eeqj.de/sneak/pixa/issues/96):
- `internal/database/schema/000.sql` → `internal/db/migrations/000_migration.sql`
- `internal/database/schema/001_initial_schema.sql` → `internal/db/migrations/001_schema.sql`
Both are `git mv` with contents unchanged; the schema does not change.
Only the migrations directory moves. The `internal/database` package stays where `CONVENTIONS.md` puts it: moving it would change the import line of five existing test files in other packages, which the repo's rules do not allow without the owner's approval.
`//go:embed` cannot reach a directory outside its own package, so `internal/db/migrations` has a small package that embeds the SQL files and returns them from `FS()`, as `internal/static` does. In `database.go` the local variables named `migrations` became `filenames`, so they do not hide that package.
Existing databases: the version comes from the filename prefix, still `000` and `001`, so a database that has recorded versions 0 and 1 runs neither again. Checked once by hand: a database created by the current `next` image on a Docker volume, opened by this branch's image, applied no migration and kept its `schema_migrations` rows unchanged.
The new test `TestApplyMigrations_SecondRunAppliesNothing`, in a new file, applies the migrations twice to one database file and fails if the second run applies any. It detects a run by the "applying" log message and first checks that the first run logs one. No existing test file changed.
Model: opus-5-5
REPO_POLICIES.md puts migrations in internal/db/migrations/ as
000_migration.sql and 001_schema.sql. The two files move there with
their contents unchanged. go:embed cannot reach outside its own
package, so internal/db/migrations has a small package that embeds
them, and internal/database reads them through its FS(). The database
package stays where CONVENTIONS.md puts it; moving it would change
existing test files in other packages.
The version still comes from the filename prefix, so a database that
has recorded versions 0 and 1 runs neither again. A new test applies
the migrations twice to one database file and checks that the second
run applies nothing.
Model: opus-5-5
PASS: the migration files sit at the path and under the names REPO_POLICIES.md sets, with contents unchanged, and keeping internal/database where it is while internal/db/migrations only embeds the files is accepted.
Model: opus-5-5
PASS: the migration files sit at the path and under the names `REPO_POLICIES.md` sets, with contents unchanged, and keeping `internal/database` where it is while `internal/db/migrations` only embeds the files is accepted.
Model: opus-5-5
clawbot
merged commit 46a55ec15d into next2026-09-29 07:42:06 +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.
Moves the migration files to the directory and names
REPO_POLICIES.mdsets, while that is still a plain rename (#96):internal/database/schema/000.sql→internal/db/migrations/000_migration.sqlinternal/database/schema/001_initial_schema.sql→internal/db/migrations/001_schema.sqlBoth are
git mvwith contents unchanged; the schema does not change.Only the migrations directory moves. The
internal/databasepackage stays whereCONVENTIONS.mdputs it: moving it would change the import line of five existing test files in other packages, which the repo's rules do not allow without the owner's approval.//go:embedcannot reach a directory outside its own package, sointernal/db/migrationshas a small package that embeds the SQL files and returns them fromFS(), asinternal/staticdoes. Indatabase.gothe local variables namedmigrationsbecamefilenames, so they do not hide that package.Existing databases: the version comes from the filename prefix, still
000and001, so a database that has recorded versions 0 and 1 runs neither again. Checked once by hand: a database created by the currentnextimage on a Docker volume, opened by this branch's image, applied no migration and kept itsschema_migrationsrows unchanged.The new test
TestApplyMigrations_SecondRunAppliesNothing, in a new file, applies the migrations twice to one database file and fails if the second run applies any. It detects a run by the "applying" log message and first checks that the first run logs one. No existing test file changed.Model: opus-5-5
PASS: the migration files sit at the path and under the names
REPO_POLICIES.mdsets, with contents unchanged, and keepinginternal/databasewhere it is whileinternal/db/migrationsonly embeds the files is accepted.Model: opus-5-5