cesnimda/jobtrackingapp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor(db): migrate Gmail review decisions

Browse Source 
Move creation ownership from startup reconciliation to an additive provider-aware migration. Preserve legacy decisions during downgrade and add the previously missing MariaDB table path.
This commit is contained in:
cesnimda
2026-08-30 16:48:32 +02:00
parent c094800c69
commit b425f1edc5
9 changed files with 106 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/infrastructure/database-ownership.md
+4 -1
View File
@@ -67,7 +67,7 @@ already-correct database. Two consequences worth knowing:
Created by EF migrations, never by the reconciler:
`AccountDeletionFiles`, `AccountDeletionRequests`, `AiUsageRecords`, `Attachments`, `Companies`,
`Correspondences`, `EmailDrafts`, `EmailSendAttempts`, `JobApplications`, `JobEvents`, `Jobs`,
`Correspondences`, `EmailDrafts`, `EmailSendAttempts`, `GmailReviewDecisions`, `JobApplications`, `JobEvents`, `Jobs`,
`RuleSettings`, `SystemEmailSettings`, `UserNotifications`, `UserOperations`, and `UserRuleSettings`.
`SystemEmailSettings` is the first completed ownership transfer: migration
@@ -77,6 +77,9 @@ an existing reconciler-created MariaDB table. Startup no longer creates it.
`UserRuleSettings` followed in `20260830121000_AdoptUserRuleSettingsSchema`; its owner-keyed rows are
preserved across adoption, downgrade and retry, and startup no longer creates it.
`GmailReviewDecisions` moved in `20260830122000_AdoptGmailReviewDecisionsSchema`. This also supplies
the table on MariaDB, where the old reconciler had no creation path.
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.
It used to create `RuleSettings`, which is precisely why a clean install failed with