chore(db): resync stale EF ModelSnapshot + fix fresh-DB schema gap #16

2026-07-11T20:33:40+02:00

cesnimda commented

2026-07-11 20:33:40 +02:00

Backlog item 1. Resyncs the empty/stale EF ModelSnapshot via a no-op migration (verified zero side effects on both a fresh DB and a copy of the dev DB). That verification surfaced a real bug: ad-hoc EnsureColumn/EnsureMySqlColumn calls no-op on a genuinely fresh database, so a brand-new deployment first boot would be missing dozens of columns until restarted. Fixed by re-running the same reconciliation once more right after Migrate() succeeds. 169/169 tests green; verified live against both a fresh empty DB and existing dev DB copy.

cesnimda added 1 commit 2026-07-11 20:33:41 +02:00

chore(db): resync stale EF ModelSnapshot + fix fresh-DB schema gap

CI and Deploy / test (pull_request) Successful in 2m1s

Details

CI and Deploy / deploy (pull_request) Has been skipped

Details

a9a0ddecbc

Backlog item 1. The committed ModelSnapshot was empty/stale (21 lines, no
entities) -- `dotnet ef migrations add` scaffolded the whole database from
scratch against it, including the ASP.NET Identity tables, which have never
been created by a real EF migration in this repo (always provisioned via the
raw-SQL reconciler in StartupInitializationExtensions.cs -- see
EnsureIdentityTables' own comment). Applying that diff for real would throw
"table/column already exists" on every environment.

Fix: added migration 20260711181039_SyncModelSnapshot with an intentionally
empty Up()/Down() (see its doc comment) -- it only records itself in
__EFMigrationsHistory and regenerates the snapshot to match the live model,
so `dotnet ef migrations add` produces a real diff for the next schema
change instead of the whole database again. Verified zero side effects
against a copy of the dev DB (only inserts one history row) and against a
fresh empty DB (full migration + reconciler chain runs clean).

That fresh-DB verification surfaced a real, previously-undiscovered bug:
EnsureColumn/EnsureMySqlColumn calls for JobApplications/Correspondences/
Companies/Attachments ad-hoc columns all no-op on a truly fresh database
(the tables don't exist yet -- Migrate() creates them afterward), so a
brand-new deployment's first boot would be missing dozens of columns
(LastReminderEmailSentAt, RecruiterMessageDraft, salary fields, Correspondence
Provider/Subject/Channel/etc.) until the next restart. Also caught: my own b4
change (Correspondence.Provider backfill, already merged) had the same
unguarded-on-fresh-DB bug in isolation.

Fixed by promoting the schema-reconciliation helpers (Exec/HasTable/
HasColumn/EnsureColumn and their MySQL equivalents) from local functions to
class-level statics, extracting the ad-hoc-column blocks into
ReconcileCoreAppColumns/ReconcileCoreAppColumnsMySql, and calling them a
second time right after Migrate() succeeds (reusing the connection already
opened for the CoreSchemaReady check) -- idempotent, so free on every boot
except the first one, where it's now required. No inline logic changed,
pure extraction + one additional call site.

Also added Microsoft.EntityFrameworkCore.Design to JobTrackerApi.csproj
(dotnet-ef tooling requires it on the startup project since EF Core 6+;
previously only referenced by JobTrackerBackend, where the DbContext lives).

169/169 backend tests green. Verified live: full app boot against both a
fresh empty SQLite DB and a copy of the populated dev DB, both clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

cesnimda merged commit 9b21d5c65d into main

2026-07-11 20:37:02 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: cesnimda/jobtrackingapp#16