refactor(db): adopt email settings migration
This commit is contained in:
cesnimda
@@ -1,6 +1,6 @@
|
||||
# Database ownership and startup order
|
||||
|
||||
> Updated 2026-08-15. Which component creates which table, in what order, and why a clean MariaDB install used
|
||||
> Updated 2026-08-30. Which component creates which table, in what order, and why a clean MariaDB install used
|
||||
> to fail. Read this before adding a table or touching `StartupInitializationExtensions`.
|
||||
|
||||
## The problem this document exists to prevent
|
||||
@@ -16,9 +16,10 @@ A composite index over one of those `TEXT`/`longtext` columns then exceeds MySQL
|
||||
limit and startup dies with `Specified key was too long`. This is not theoretical — it crashed
|
||||
production once (Phase 4 `CvVariants`) and made every clean MariaDB install fail until 2026-07-19.
|
||||
|
||||
**Rule: a table whose migration was scaffolded against SQLite must not be created by that migration
|
||||
on MariaDB.** Empty the migration and give the table to the reconciler, which carries correct DDL per
|
||||
provider.
|
||||
That historical workaround created two schema owners and is now being retired under JT-019. New
|
||||
tables belong to migrations. When the generated operation is not provider-safe, hand-author a
|
||||
provider-aware migration (using `ActiveProvider`) instead of adding more startup DDL. The reconciler
|
||||
is compatibility code for tables and columns that already shipped under its ownership.
|
||||
|
||||
## Startup order
|
||||
|
||||
@@ -65,10 +66,13 @@ already-correct database. Two consequences worth knowing:
|
||||
|
||||
Created by EF migrations, never by the reconciler:
|
||||
|
||||
`Companies`, `JobApplications`, `Jobs`, `Correspondences`, `Attachments`, `JobEvents`,
|
||||
`RuleSettings`, and the ASP.NET Identity tables. Two compatibility migrations use guarded
|
||||
`CREATE TABLE IF NOT EXISTS` bootstraps for `AspNetUsers` and `AiInteractions` so standalone EF
|
||||
tooling can traverse the historical chain; normal application startup makes those statements no-ops.
|
||||
`AccountDeletionFiles`, `AccountDeletionRequests`, `AiUsageRecords`, `Attachments`, `Companies`,
|
||||
`Correspondences`, `EmailDrafts`, `EmailSendAttempts`, `JobApplications`, `JobEvents`, `Jobs`,
|
||||
`RuleSettings`, `SystemEmailSettings`, `UserNotifications`, and `UserOperations`.
|
||||
|
||||
`SystemEmailSettings` is the first completed ownership transfer: migration
|
||||
`20260830120000_AdoptSystemEmailSettingsSchema` creates it for both supported providers and preserves
|
||||
an existing reconciler-created MariaDB table. Startup no longer creates it.
|
||||
|
||||
The reconciler may **repair** these (add a missing column, add an index, fix a non-`AUTO_INCREMENT`
|
||||
primary key) and may seed the default `RuleSettings` row — but it must never `CREATE TABLE` them.
|
||||
@@ -79,7 +83,7 @@ It used to create `RuleSettings`, which is precisely why a clean install failed
|
||||
|
||||
Created by `StartupInitializationExtensions`, with a **no-op migration** holding the model snapshot:
|
||||
|
||||
`UserRuleSettings`, `SystemEmailSettings`, `CvUploadArtifacts`, `CvExtractionRuns`,
|
||||
`UserRuleSettings`, `CvUploadArtifacts`, `CvExtractionRuns`,
|
||||
`GmailConnections`, `MicrosoftGraphConnections`, `ImapConnections`, `TailoredCvDrafts`,
|
||||
`CareerProfiles`, `CareerProfileVersions`, the six CareerProfile children (`CareerExperiences`,
|
||||
`CareerEducations`, `CareerSkills`, `CareerProjects`, `CareerCertifications`, `CareerLanguages`),
|
||||
@@ -87,6 +91,14 @@ Created by `StartupInitializationExtensions`, with a **no-op migration** holding
|
||||
`ApplicationChecklistItems`, `CoverLetterVersions`, `InterviewPrepItems`, `TwoFactorRecoveryCodes`,
|
||||
`TrustedDevices`, `UserSessions`.
|
||||
|
||||
The seven ASP.NET Identity tables are also currently reconciler-owned, despite older wording that
|
||||
called them migration-owned: `AspNetRoles`, `AspNetUsers`, `AspNetRoleClaims`, `AspNetUserClaims`,
|
||||
`AspNetUserLogins`, `AspNetUserRoles`, and `AspNetUserTokens`. Guarded migration bootstraps for
|
||||
`AspNetUsers` and `AiInteractions` support standalone traversal but do not yet transfer ownership.
|
||||
|
||||
`StartupSchemaOwnership` is the executable inventory. Its tests require every EF model table to
|
||||
have exactly one creation owner and keep compatibility bootstraps out of the migration-owned set.
|
||||
|
||||
No-op migrations, each with a comment explaining why:
|
||||
|
||||
| Migration | Tables |
|
||||
@@ -119,11 +131,27 @@ as well as index existence — repairing an absent table is not pass 1's job.
|
||||
1. Add the entity and its `DbSet`, and **bound every indexed string** with `HasMaxLength` — an
|
||||
unbounded string becomes `longtext`, which MariaDB cannot index without a prefix length. This is
|
||||
what broke the CareerProfile children.
|
||||
2. `dotnet ef migrations add …`, then **empty the `Up`/`Down`** and say why in a comment.
|
||||
3. Add SQLite DDL (`CREATE TABLE IF NOT EXISTS`) and MySQL DDL (`int AUTO_INCREMENT`, `varchar(n)`,
|
||||
`datetime(6)`, `tinyint(1)`) to the reconciler. Guard the MySQL create on any parent table.
|
||||
4. Create indexes via `EnsureMySqlIndex` / `CREATE INDEX IF NOT EXISTS`.
|
||||
5. Verify on a real MariaDB container — see below. EF InMemory will not catch any of this.
|
||||
2. Add an EF migration. Review its generated SQL for both SQLite and MariaDB; do not assume a
|
||||
SQLite-scaffolded type is valid on MariaDB.
|
||||
3. If needed, replace the generated operation with provider-aware migration SQL (`int
|
||||
AUTO_INCREMENT`, bounded `varchar(n)`, `datetime(6)`, `tinyint(1)` on MariaDB). Do not add the
|
||||
table to `StartupInitializationExtensions`.
|
||||
4. Classify the table in `StartupSchemaOwnership.MigrationOwnedTables`; the ownership test will fail
|
||||
if it is omitted or duplicated.
|
||||
5. Verify blank, populated-upgrade and restart paths on SQLite and a real MariaDB container. EF
|
||||
InMemory will not catch provider DDL defects.
|
||||
|
||||
## Retiring a reconciler-owned table
|
||||
|
||||
Move one leaf/dependency group at a time:
|
||||
|
||||
1. Add an idempotent provider-aware migration that creates the legacy shape when absent.
|
||||
2. Make downgrade preserve a table that may predate migration ownership; never drop ambiguous data.
|
||||
3. Remove only that table's startup `CREATE TABLE` block and move it between the executable ownership sets.
|
||||
4. Prove a blank database, a pre-migration database with a representative row, migration retry, and
|
||||
provider SQL/runtime behaviour.
|
||||
5. Leave column/index repairs in place until historical upgrade fixtures prove they are redundant;
|
||||
table creation and legacy repair are separate ownership decisions.
|
||||
|
||||
## Fresh install
|
||||
|
||||
|
||||
Reference in New Issue
Block a user