cesnimda
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>
29 lines
1.2 KiB
XML
29 lines
1.2 KiB
XML
<Project Sdk="Microsoft.NET.Sdk.Web">
|
|
|
|
<PropertyGroup>
|
|
<TargetFramework>net9.0</TargetFramework>
|
|
<Nullable>enable</Nullable>
|
|
<ImplicitUsings>enable</ImplicitUsings>
|
|
<RestoreIgnoreFailedSources>true</RestoreIgnoreFailedSources>
|
|
</PropertyGroup>
|
|
|
|
<ItemGroup>
|
|
<Compile Remove="Controllers\**\*.cs" />
|
|
<Compile Remove="Services\**\*.cs" />
|
|
<PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="9.0.14" />
|
|
<PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="9.0.14" />
|
|
<PackageReference Include="Pomelo.EntityFrameworkCore.MySql" Version="9.0.0" />
|
|
<!-- dotnet-ef design-time tooling requires this on the startup project (not just
|
|
JobTrackerBackend, where the DbContext actually lives) since EF Core 6+. -->
|
|
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="9.0.14">
|
|
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
|
|
<PrivateAssets>all</PrivateAssets>
|
|
</PackageReference>
|
|
</ItemGroup>
|
|
|
|
<ItemGroup>
|
|
<ProjectReference Include="..\JobTrackerBackend\JobTrackerBackend.csproj" />
|
|
</ItemGroup>
|
|
|
|
</Project>
|