corentin_wakdo/db/README.md
Imugiii 56b26db0c1
All checks were successful
CI / auto-merge (pull_request) Successful in 4s
CI / secret-scan (pull_request) Successful in 9s
CI / php-lint (pull_request) Successful in 21s
CI / static-tests (pull_request) Successful in 42s
CI / js-tests (pull_request) Successful in 19s
chore: remplace le Makefile par un service compose wakdo-migrate (migrate + seed idempotents)
Le Makefile portait surtout des cibles mortes/trompeuses (test/test-unit/
test-integration/lint annoncaient "pas implemente" alors que les tests tournent ;
install-hooks pointait sur des fichiers absents) ; sa seule cible porteuse, `init`,
existait parce que `docker compose up` seul n'applique pas les migrations.

En deplacant migrate + seed DANS la stack, `docker compose up` devient l'unique
commande qui amene une stack complete et loginnable -> Cr 7.c.4 satisfait sans
dependance a l'outil `make`.

- db/migrate-container.sh : runner in-container (connexion par le reseau compose),
  applique db/migrations/*.sql (suivi schema_migrations) puis db/seeds/*.sql (suivi
  seeds_applied), idempotent.
- Service one-shot `wakdo-migrate` (depends_on db healthy) ; wakdo-app/web attendent
  sa completion (service_completed_successfully).
- Makefile supprime ; db/migrate.sh (hote) conserve pour l'usage manuel / --status.
- Docs realignees : README, .env.example, db/README, docker-compose, PROJECT_CONTEXT
  (`make *` -> `docker compose *`, Cr 7.b porte par les scripts Bash). Correction au
  passage : la CI/CD est Forgejo Actions (pas GitHub Actions), protections cote Forgejo.
- Journal : docs/journal/2026-06-17--makefile-to-compose-migrate.md (rationale + verif
  sur base ephemere : 2 migrations + 2 seeds, idempotent ; note de deploiement pour
  les bases deja seedees).

Verifie : docker compose config valide ; runner teste sur MariaDB ephemere (5 roles,
23 permissions, admin present) ; re-run = 0 nouveau. Aucun code PHP/JS touche.
2026-06-17 12:41:36 +00:00

38 lines
1.6 KiB
Markdown

# Base de donnees - migrations & seeds
Transcription executable du MLD (`docs/merise/mld.md`, 21 tables) vers MariaDB 11.4.
## Arborescence
```
db/
migrations/ migrations SQL versionnees, appliquees dans l'ordre lexicographique
0001_init_schema.sql schema initial : 21 tables, FK, CHECK, index (InnoDB, utf8mb4)
seeds/ donnees de demonstration (a venir : roles/permissions, allergenes, catalogue)
migrate.sh runner de migrations (idempotent)
```
## Appliquer les migrations
```bash
bash db/migrate.sh # applique les migrations en attente
bash db/migrate.sh --status # liste l'etat sans rien appliquer
```
Le runner cible le conteneur `wakdo-db` et lit les identifiants dans `.env`
(`DB_NAME`, `DB_ROOT_PASSWORD`). Il maintient une table `schema_migrations`
(une ligne par fichier applique) : relancer ne rejoue que les nouvelles
migrations. La cible `bash db/migrate.sh` est destinee a appeler ce script.
## Conventions
- Une migration = un fichier `NNNN_description.sql`. Un fichier deja applique en
commun n'est plus edite : on ajoute une nouvelle migration pour corriger.
- Pas de `CREATE DATABASE` / `USE` dans les fichiers : la base cible est choisie
par le runner.
- Le schema suit le MLD v0.2 a la lettre : montants en centimes (INT UNSIGNED),
`vat_rate` en pour-mille, `service_day` NON materialise (calcule applicatif,
decision D6), stock signe (survente), journaux append-only (`stock_movement`,
`audit_log`).
- Verification : le DDL a ete applique sur une instance MariaDB 11.4 reelle
(21 tables, 28 FK, 22 CHECK) sans erreur avant integration.