[lesomnus]

For lesomnus/payday#33's directory (#7), and for the planned one beside it. Both are applied by Migrations.Apply, on every start, and by every replica that starts.

What was wrong

• Two processes could apply one directory at once. Nothing in Apply or in atlas's Executor locks; the Atlas CLI takes schema.Locker itself. On PostgreSQL:
  • Both processes create the history table. The second is refused with duplicate key value violates unique constraint "pg_type_typname_nsp_index", despite IF NOT EXISTS.
  • Both run a pending file's statements. The second to reach one that cannot run twice fails (relation "once" already exists), and its deferred revision write replaces the winner's record.
  • I reproduced that last case: the history then reads applied=1 total=2 error="… already exists". Every later Apply reruns the file, fails the same way, and the deployment cannot start until someone fixes the row by hand.
• An applied file that was edited afterwards went unnoticed. Atlas compares a file's statements only while the file is half-applied, and atlas.sum is whatever Rehash last wrote. So an edit plus a rehash changed nothing in a database that had already run the file, and changed what ran in the next database migrated. Nothing reported the difference.

What changed

• Apply holds a session advisory lock (pg_advisory_lock) from before it creates the history table until the files have run.
  • The key is an FNV-64 of the schema and the history table. The two directories of one database, or two schemas in one database, do not wait on each other.
  • A waiting process waits as long as ctx allows, then finds nothing pending.
  • A process that dies releases the lock with its session. If the unlock itself fails, the connection is discarded rather than returned to the pool still holding the lock.
  • SQLite takes no lock. Atlas's SQLite locker is a file in os.TempDir() keyed by name, which would serialize unrelated databases, and several processes migrating one SQLite file is not a supported setup.
• ErrEdited. Pending, Apply and Current compare each fully applied revision's stored hash with the directory's hash for that file, and refuse a mismatch, naming the files.
  • Atlas's per-file hash covers the directory up to and including the file. So an edit, addition or removal before a file the database ran also changes that file's hash. All three rewrite history under a database that ran it, and atlas already refuses an older file added out of order.
  • Baselines, and files still half-applied (atlas checks those statement by statement), are skipped.
• CI: the unit job gets a postgres:17 service. The schema migration step gets ENT_SCHEMA_POSTGRES; its tests create a database of their own and drop it.
• dialect/sql/schema/integration requires lib/pq v1.10.7, the version entc/integration already pins.

And what the directory needs: files, not Schema.Create

The second commit records why Schema.Create keeps dropping undeclared foreign keys and checks. One option was to make its default skip match Check's, so it would leave them alone. I did not, because Create drops them on purpose: that is how it retires a constraint the schema stopped declaring.

• An edge pointed at another table gets a foreign key under a new name (<table>_<ref>_<edge>). Left in place, the old key would refuse every row the new one allows.
• Create cannot tell that stale key from one the extra directory made, so it drops both.
• The extra directory's history still says the file ran, so nothing recreates them. On PostgreSQL 17 I checked that a CHECK and a foreign key added beside the schema are gone after the next Create.
• On SQLite, most changes rebuild the table from the schema, which drops them as well.

So the package doc and Extra now say the directory is for a database migrated from files. An app that migrates with Create instead runs its DDL after every Create, with each statement safe to run again; rove's cli/pg.sql works this way.

Tests

• TestApplyIsOneAtATime (PostgreSQL; skipped without ENT_SCHEMA_POSTGRES): two pools apply the same directory concurrently.
  • First, a file that also creates the history table.
  • Then a file of SELECT pg_sleep(0.5); CREATE TABLE once ….
  • Both calls must succeed, and the history must say applied = total with no error.
• TestEdited (SQLite):
  • a file added after the ones applied is not an edit;
  • an applied file edited and rehashed is refused by Pending, Apply and Current, and the error names it;
  • a fresh database runs the files as they are.
• Mutations:
  • with the lock skipped, both phases of TestApplyIsOneAtATime fail, three runs out of three (the catalog duplicate, then relation "once" already exists);
  • with the check skipped, TestEdited fails.
• go test -race ./... passes in dialect and, with PostgreSQL 17, in dialect/sql/schema/integration. .github/lint.sh is clean on the changed files.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KxtnpRW533bdErnW8QPhsk