O Banco de Dados

O Chinaski armazena tudo em um único arquivo SQLite por instância. Sem servidor de banco de dados, sem credenciais, sem protocolo de rede. E mantém seu schema atualizado com migrações idempotentes que rodam automaticamente na inicialização.

Um arquivo por instância

O banco de dados é um único arquivo chinaski.db, por padrão na raiz da aplicação, ou onde quer que sua variável de ambiente CHINASKI_DB aponte. Cada instância que você roda (chinaski@1, chinaski@prod, uma cópia de staging. Tem seu próprio arquivo e suas próprias configurações; os templates de unit de produção derivam esses caminhos por nome de instância, de modo que cópias nunca colidam.

As conexões passam por um único módulo compartilhado com um conjunto canônico de opções: erros aparecem imediatamente, o texto é limpo em Unicode, e um busy timeout de 5 segundos impede que um arquivo bloqueado deixe uma requisição pendurada. O modo WAL é definido persistentemente, de modo que leitores não bloqueiam escritores e a carga de trabalho típica. Uma sessão de admin ativa mais builds periódicos: continua ágil. As verificações de saúde no endpoint do tipo /health confirmam leitura, escrita e modo de journal, avisando quando o WAL não está ativo.

Como o schema evolui

• Instalações novas são semeadas pelo schema.sql, o schema completo para um banco de dados novo; os scripts de instalação o executam para você (ou você pode rodar sqlite3 chinaski.db < schema.sql à mão).
• Os arquivos numerados sob migrations/ não são aplicados mecanicamente a instâncias em execução. Eles documentam a evolução e servem apenas a instalações novas.
• Instâncias já implantadas são atualizadas por meio de subs de migração idempotentes ligadas a uma única rotina de inicialização. Cada migração primeiro introspecta o banco de dados: a coluna ou tabela já existe? Ele não faz nada quando existe. Casos de primeiro boot pulam estas inteiramente porque o schema.sql criou a forma nova.

Como elas rodam na inicialização e são idempotentes, atualizar o Chinaski é subir o serviço e seguir em frente: a instância cura o próprio schema no caminho.

O que há dentro

Tudo o que o CMS gerencia: páginas, posts, blocos, snippets, stacks, categorias, redirecionamentos, navegação, formulários com seus envios, metadados de mídia, documentos, usuários e sessões, os logs de auth/auditoria/eventos, o log de build com relatórios de validação, o render cache, configurações chave-valor, históricos de revisões e registros de execuções de backup.

Duas notas de confidencialidade que vale conhecer:

• Credenciais que você insere nas configurações (senhas SMTP, chaves de API, segredos de armazenamento) são armazenadas criptografadas no banco de dados, derivadas do segredo da sua instância: nunca em texto plano.
• Um carimbo de versão de schema amarra o layout do arquivo às expectativas do código, e é o mesmo número que o fluxo de backup/restauração verifica. Um banco de dados restaurado sobre uma instância de versão diferente é recusado, em vez de parcialmente aplicado.

Saúde e manutenção

A manutenção é embutida: tokens de redefinição de senha expirados, sessões mortas e históricos de log limitados são podados automaticamente na inicialização e em timers periódicos. O endpoint /health verifica que o banco de dados pode ser lido e escrito e informa o modo de journal, de modo que desvios da configuração esperada sejam detectados antes que mordam.

Backups são cópias de arquivo comuns. Nenhum ferramental especial é necessário. E as páginas dedicadas de backup cobrem snapshots, retenção e restauração.