FIREFLO_DB_URL sin establecer y FireFlo corre sobre archivos, con los call records
escritos en data/cdr/.
Qué te compra
La mitad de solo lectura del panel funciona sin ella; simplemente no tiene nada que cambiar.
Crearla
Instala primero el servidor si el host no tiene ninguno —setup.sh lo hace y ahí se detiene deliberadamente, porque un
script que acuña la contraseña de tu base de datos es un script que ha escrito una credencial en disco
en tu nombre. El rol y la base de datos te corresponde crearlos a ti:
Aplicar el esquema
FIREFLO_DB_MIGRATE=true migra al arrancar, lo cual es conveniente para una primera vez y equivocado para una
actualización. Ata un cambio de esquema a un arranque de proceso y no te da forma de ver lo que se aplicaría
antes.
info y validate no necesitan el flag que habilita escritura. Leer la versión del esquema no cambia
nada, y necesitar un flag antes de poder mirar sería una trampa en mitad de un incidente.
db migrate solo no es suficiente
Este es el que pilla a la gente, y el fallo es sonoro en lugar de elegante.
db migrate crea las tablas y deja cada una de ellas vacía. Sin tabla de enrutamiento el
gateway no arranca en absoluto:
fireflo bootstrap escribe lo mínimo que arrancará.
La línea base consolidada
El esquema es un archivo,V1.19.0__baseline.sql, generado en lugar de fusionado a mano: los originales
se aplicaron a una base de datos de trabajo, se volcaron con pg_dump --schema-only, y el volcado se verificó
aplicándolo a una segunda base de datos y comparando ambas. Los cambios posteriores continúan en V1.20.0.
Está numerado a la versión más alta que reemplaza, no a la más baja, deliberadamente. Un despliegue que
se detuvo a mitad trataría una línea base con número menor como ya aplicada y migraría a un no-op,
perdiendo silenciosamente lo que viniera después. En 1.19.0 intenta aplicar y falla en la primera
tabla que ya existe. Recuperable, donde la versión silenciosa corrompe por omisión.
Actualizar un despliegue que aplicó los originales
La historia de Flyway aún los nombra a todos, así quedb validate falla hasta que el registro se realinea: un
checksum cambiado, el resto ya no resolubles. Un comando lo arregla, y reescribe la historia
en lugar del esquema:
Actualizar, en orden
1
Para el gateway
2
Mira, luego aplica
3
Arranca la nueva versión
db migrate corre en ambos empaquetados. Una instalación nativa se migra a sí misma — el comando está
dentro del ejecutable del gateway, así que no se necesitan ni un JDK ni un segundo artefacto.
Las claves y tablas están en Configuración de base de datos.