lrvo-db

lrvo-db gère le schéma de la base : création des tables du core et de tous les modules découverts, test de connexion, suppression.

npx lrvo-db <commande>

Sans argument, la commande affiche son aide.

Commandes

init

npx lrvo-db init

  ◆ Initializing database...
  ✓ DB ready — 7 tables created, 0 skipped

La commande charge les modules installés, enregistre leurs permissions, applique le seed, puis appelle le createTables() de chaque module.

Elle est idempotente : une table qui existe déjà est comptée dans skipped, pas recréée. C'est ce qui permet de la relancer après chaque npm install @lrvo/module-X sans risque.

À lancer :

• après l'installation initiale du projet ;
• après l'ajout d'un module qui déclare des tables ;
• après une mise à jour de module qui ajoute des tables.

migrate

npx lrvo-db migrate

Deux effets, et le second est moins évident que le premier.

Elle applique les migrations en attente, du core puis de chaque module, une transaction par migration et sous verrou consultatif.

Elle aligne ensuite le catalogue de permissions sur le code installé, et attribue au rôle admin tout ce qui s'y trouve. Sans cette étape, une permission ajoutée par une version ultérieure du core ou par un module installé après coup n'atteindrait jamais une base déjà initialisée : le seed complet ne tourne qu'à l'init, que rien n'enchaîne. migrate est enchaîné par lrvo-update et fait partie de toute procédure de déploiement.

La resynchronisation est idempotente, hors du verrou, et ne retire jamais une permission. Elle ne touche à aucun rôle autre que admin. Sur une base sans tables de permissions, elle ne fait rien et le signale.

test

npx lrvo-db test

Vérifie que LRVO_DATABASE_URL (ou LRVO_DATABASE_URL_DEV en développement) pointe vers une base joignable. Premier réflexe quand l'application démarre mais que rien ne se charge.

drop

npx lrvo-db drop

  ⚠ This will delete all tables!
  Type "yes" to confirm or Ctrl+C to cancel...
  Confirm (yes/no):

Supprime toutes les tables, celles du core comme celles des modules. Toute autre réponse que yes annule.

Réservé au développement. Il n'y a pas de sauvegarde et pas de retour en arrière.

Notes

Les migrations sont versionnées et journalisées. Chaque paquet déclare un tableau migrations, et la table lrvo_migrations retient ce qui a été appliqué. Une migration ne repasse jamais. Voir Écrire une migration.

Une base existante n'est jamais rejouée. À la première exécution sur une base donnée, chaque paquet reçoit une ligne 000-baseline posée après son createTables(), qui fige le schéma courant. Aucun CREATE TABLE n'est rejoué sur des tables pleines.

Tout le travail de schéma se fait sous verrou consultatif. Deux répliques de déploiement qui lancent init en même temps se sérialisent, et la seconde reçoit un message clair au lieu d'un blocage.

Les permissions sont enregistrées avant le seed. Les permissions déclarées dans le manifest d'un module sont ajoutées au catalogue puis attribuées au rôle admin au moment du init. Un module ajouté après coup n'a donc besoin que d'un npx lrvo-db init pour que ses permissions apparaissent dans /admin/roles.

Le pool est fermé proprement en fin d'exécution, y compris sur erreur.