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

docs(database): record MariaDB qualification and retirement gates
MariaDB persistence qualification / mariadb (push) Failing after 1m7s
Details

Browse Source
This commit is contained in:
cesnimda
2026-10-24 01:52:03 +02:00
parent a2c9bda0d1
commit e75c4a4775
20 changed files with 14568 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/database/migrations.md
+5 -1
View File
@@ -1,6 +1,10 @@
# Migrations and compatibility
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.
The API applies EF Core migrations on startup and performs guarded legacy-schema reconciliation.
MariaDB is the standard; fresh/repeated/populated disposable MariaDB startup and persisted-state
tests are the database integration lane. Explicit SQLite compatibility remains temporarily for
existing data/legacy tests. Generated SQL and SQLite passes are not MariaDB runtime evidence.
See [current qualification](mariadb-standardisation/README.md); no production migration is authorized here.
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.