Construire un module

Base de données & migrations

Chaque module possède son propre schéma PostgreSQL, isolé du core et des autres modules. Les requêtes sont vérifiées à la compilation par SQLx.

Isolation par schéma #

Un module nommé calendar ne crée des tables que dans le schéma calendar. Aucune clé étrangère ne traverse les schémas : les modules restent découplés.

Migrations #

Les migrations vivent dans migrations/, versionnées et numérotées. Elles sont appliquées au démarrage (ou via la CLI). Convention de nommage :

migrations/
├── 000001_calendar_schema.up.sql
├── 000001_calendar_schema.down.sql
├── 000002_calendar_attendees.up.sql
└── 000002_calendar_attendees.down.sql

Astuce

Le core lui-même suit la même convention (schéma core) : users, sessions, modules, settings, jobs, event_log, thèmes, MCP, push…

SQLx & cache hors-ligne #

Les requêtes utilisent les macros vérifiées à la compilation (sqlx::query_as!). Un cache .sqlx permet de builder sans base (CI, paquets) :

# Build hors-ligne (utilise le cache .sqlx, aucune DB requise)
SQLX_OFFLINE=true cargo build --release

# Régénérer le cache après un changement de requête/schéma
DATABASE_URL=postgres://… cargo sqlx prepare   # puis commitez le dossier .sqlx

Connexion injectée #

Le superviseur du core fournit au processus du module ses identifiants de base via l'environnement (KUBUNO_DB_HOST, KUBUNO_DB_PORT, KUBUNO_DB_USER, KUBUNO_DB_PASSWORD, KUBUNO_DB_NAME).