You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 705be1b
Browse filesBrowse the repository at this point in the historyBrowse files
test(migrate): close the uuid-PK blind spot; fix two Postgres non-convergence bugs it found
Every PK in every migrate fixture was `field.long` + `@generation: increment`,
so an entire family of uuid-PK migrate bugs was invisible to 5000+ tests. This
adds the missing coverage — and the new gates immediately caught two REAL,
previously-unknown Postgres bugs that make `meta migrate` never converge.
Coverage (test/fixtures/trainer-website-entities.json):
MediaAsset — a uuid-PK kitchen sink. One shape per shipped bug: a uuid PK, an
FK from a long-PK table INTO it, a paren-bearing string default, a
quote-bearing string default, a boolean @default false, a field.enum, an
@autoset timestamp, a partial (@where) UNIQUE, an expression (@expr) index, a
@orders:desc index, a @constraintName FK, and a @precision/@scale decimal.
It feeds the existing SQLite AND Postgres round-trip gates, both of which
already apply-then-re-diff, so both engines now cover uuid PKs for free.
test/integration/sqlite-uuid-pk-kitchen-sink.test.ts runs BOTH required gates
against real libsql: IDEMPOTENCE (apply → introspect → re-diff must be EMPTY)
and VALUE SEMANTICS (insert a row taking the defaults, then ask the engine what
it actually stored). Neither alone suffices: idempotence is blind to
consistently-wrong behavior (emit and introspect happily agreed on
DEFAULT 'false' while SQLite stored the TEXT "false" and `= 0` matched nothing),
and value semantics is blind to asymmetry.
Two REAL bugs found by the new gates, both making `meta migrate` exit 1 forever:
1. Postgres introspection never read numeric precision/scale. The column query
selected data_type — a bare "numeric" for every NUMERIC(p,s) — and
character_maximum_length, which is NULL for numerics. So a
`field.decimal @precision @scale` column diffed as a change-column-type on
EVERY migrate, and being lossy it was BLOCKED. Any Postgres schema with a
decimal column could never converge. Now selects numeric_precision /
numeric_scale and passes them out-of-band. (The existing unit tests only
ever fed pgTypeToSqlType the inline string "numeric(10,2)" — a form the real
information_schema query never produces.)
2. NUMERIC(p) IS NUMERIC(p,0). A precision-only decimal modeled no scale, but
Postgres stores and reports scale 0, so expected and introspected could
never converge. expected-schema now models the scale the database will hold.
Test-shape fix: sqlite-roundtrip / postgres-roundtrip called diff() WITHOUT a
dialect — a shape the production CLI never produces. Two behaviors hang off it:
FKs are keyed STRUCTURALLY on sqlite (which stores no FK names, so a
@constraintName can never match by name), and CHECK constraints are only diffed
when a dialect is known — so an enum @values change was invisible. Both gates
were silently disarmed; they now call diff() exactly as the CLI does.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hd5NWZ1rKau63vJzrBSpLb
0 commit comments