Skip to main content
O PostgreSQL é opcional. Deixe FIREFLO_DB_URL sem definir e o FireFlo roda com arquivos, com call records escritos em data/cdr/.

​
O que ele te dá

A metade somente-leitura do painel funciona sem ele; só não tem nada para alterar.

​
Criando

Instale o servidor primeiro se o host não tiver nenhum — o setup.sh faz isso e deliberadamente para por aí, porque um script que cunha a senha do seu banco é um script que escreveu uma credencial em disco em seu nome. A role e o banco são seus para criar:

​
Aplicando o schema

FIREFLO_DB_MIGRATE=true migra no startup, o que é conveniente para uma primeira execução e errado para uma atualização — vincula uma mudança de schema a um start de processo e não dá nenhuma forma de você ver antes o que seria aplicado.
info e validate não precisam da flag que habilita escrita. Ler a versão do schema não muda nada, e precisar de uma flag antes de você poder olhar seria uma armadilha no meio de um incidente.
Migrations são unidirecionais. Não há scripts de undo, então reverter uma mudança de schema significa restaurar um backup. Faça um antes de migrar um banco com o qual você se importa.

​
db migrate sozinho não é suficiente

Este é o que pega as pessoas, e a falha é ruidosa em vez de suave. db migrate cria as tabelas e deixa todas elas vazias. Sem tabela de roteamento o gateway não inicia:
Isso nomeia uma estrutura interna em vez da linha faltando, então parece um bug. Não é — significa que o banco está vazio. fireflo bootstrap escreve o mínimo que fará o gateway iniciar.

​
O baseline consolidado

O schema é um arquivo, V1.19.0__baseline.sql, gerado em vez de mesclado à mão: os originais foram aplicados a um banco descartável, dumped com pg_dump --schema-only, e o dump verificado aplicando-o a um segundo banco e comparando os dois. Mudanças posteriores continuam a partir de V1.20.0. Ele é numerado na maior versão que substitui, não na menor, deliberadamente. Um deployment que parou no meio trataria um baseline com número menor como já aplicado e migraria para um no-op, perdendo silenciosamente o que veio depois. Em 1.19.0 ele tenta aplicar e falha na primeira tabela que já existe — recuperável, enquanto a versão silenciosa corrompe por omissão.

​
Atualizando um deployment que aplicou os originais

O histórico do Flyway ainda nomeia todos eles, então db validate falha até o registro ser realinhado: um checksum alterado, o resto não mais resolvível. Um comando corrige, e reescreve o histórico em vez do schema:
Termine de aplicar qualquer migration pendente antes de rodar repair. Repair em um banco parcialmente migrado faz parecer que ele está completo quando não está.

​
Atualizando, em ordem

1

Pare o gateway

2

Olhe, depois aplique

3

Inicie a nova versão

db migrate roda em ambos os empacotamentos. Uma instalação nativa migra a si mesma — o comando está dentro do executável do gateway, então nenhum JDK e nenhum segundo artefato são necessários. Chaves e tabelas estão em Database configuration.