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

fix(database): enable SQLite WAL before schema reconciliation

Browse Source
This commit is contained in:
cesnimda
2026-10-21 08:04:26 +02:00
parent a15336cc94
commit f51e0506cc
10 changed files with 594 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/database/migrations.md
+2
View File
@@ -2,6 +2,8 @@
The API applies EF Core migrations on startup and performs guarded legacy-schema reconciliation for SQLite and MariaDB/MySQL compatibility. Fresh and repeated disposable SQLite migration chains are the normal local verification; generated provider SQL is not proof of a live production migration.
SQLite startup explicitly enables write-ahead logging (WAL) before reconciliation opens the database file. This lets concurrent readers coexist with committed usage and preference writes; it changes journaling, not stored fields or ownership. MariaDB/MySQL initialization is unchanged. Use the existing `VACUUM INTO` backup runner for a consistent SQLite snapshot, including committed WAL contents; copying only a running database's `.db` file is insufficient. Disposable startup, held-reader/write and independent backup tests cover this boundary; they do not replace production restore qualification.
The `Job`/`JobApplication` opportunity cutover is an expand/verify/contract change. Keep dual writes and compatibility reads until a production report and restored-backup rehearsal pass, then observe one release before removing legacy columns in a later migration. Never edit the history of an applied migration.
### Production cutover validation