FIREFLO_DB_URL non défini et FireFlo tourne sur fichiers, avec les enregistrements d’appels écrits dans data/cdr/.
Ce que ça apporte
La moitié en lecture seule du panel fonctionne sans ; elle n’a juste rien à changer.
La créer
Installez d’abord le serveur si l’hôte n’en a pas —setup.sh le fait et s’arrête là délibérément, parce qu’un script qui frappe votre mot de passe de base de données est un script qui a écrit un identifiant sur disque à votre place. Le rôle et la base sont à vous de créer :
Appliquer le schéma
FIREFLO_DB_MIGRATE=true migre au démarrage, ce qui est pratique pour une première exécution et faux pour une mise à niveau. Cela lie un changement de schéma à un démarrage de processus et ne vous laisse aucun moyen de voir ce qui serait appliqué d’abord.
info et validate n’ont pas besoin du drapeau d’activation d’écriture. Lire la version du schéma ne change rien, et avoir besoin d’un drapeau avant de pouvoir regarder serait un piège en pleine incident.
db migrate seul ne suffit pas
C’est celui qui piège les gens, et l’échec est bruyant plutôt que gracieux.
db migrate crée les tables et laisse chacune vide. Sans table de routage le gateway ne démarre pas du tout :
fireflo bootstrap écrit le minimum pour démarrer.
La baseline consolidée
Le schéma est un fichier,V1.19.0__baseline.sql, généré plutôt que fusionné à la main. Les originaux ont été appliqués à une base brouillon, exportés avec pg_dump --schema-only, et l’export vérifié en l’appliquant à une seconde base et en comparant les deux. Les changements ultérieurs continuent à V1.20.0.
Il est numéroté à la version la plus haute qu’il remplace, pas la plus basse, délibérément. Un déploiement arrêté en cours de route traiterait une baseline avec un numéro plus bas comme déjà appliquée et migrerait à un no-op, manquant silencieusement tout ce qui venait après. À 1.19.0 il essaie plutôt d’appliquer et échoue sur la première table qui existe déjà. Récupérable, là où la version silencieuse corrompt par omission.
Mettre à niveau un déploiement qui a appliqué les originaux
L’historique de Flyway les nomme toujours tous, doncdb validate échoue jusqu’à ce que l’enregistrement soit réaligné : un checksum changé, le reste non plus résoluble. Une commande le corrige, et elle réécrit l’historique plutôt que le schéma :
Mettre à niveau, dans l’ordre
1
Arrêter le gateway
2
Regarder, puis appliquer
3
Démarrer la nouvelle version
db migrate tourne sur les deux formats. Une installation native se migre elle-même — la commande est dans l’exécutable du gateway, donc aucun JDK ni second artefact n’est nécessaire.
Les clés et tables sont dans Configuration de la base.