SQL congelado

Algumas migrations não trazem o SQL inline: elas leem um arquivo .sql no momento em que são aplicadas. Se esse arquivo fosse editado depois do merge, um banco novo receberia a versão nova e todo banco que já rodou a migration ficaria com a antiga, sem aviso. Por isso a regra:

SQL escrito à mão que uma migration carrega fica congelado depois do merge. Uma mudança posterior vai num arquivo novo, carregado por uma migration nova.

Todo arquivo congelado começa com a linha:

-- FROZEN once merged: later changes go in a new file loaded by a new migration.

Os arquivos fixadosCopiar link

apps/migrator/migrations/frozen-sql.json fixa o sha256 de cada arquivo carregado por uma migration. Hoje são 16:

Alguns constraints.sql são intencionalmente vazios (só comentários), quando tudo do domínio é expresso pelas entities; eles continuam fixados.

O que o migrations:check recusaCopiar link

• um arquivo carregado cujo sha256 difere do fixado (editado);
• um arquivo carregado sem entrada no frozen-sql.json (não fixado);
• uma entrada que não corresponde a nenhum arquivo carregado (obsoleta).

Fixe o arquivo novo no mesmo commit que adiciona a migration que o carrega.

Exemplo: a correção de concorrência do teto de escopoCopiar link

A checagem do teto de escopo, criada em 0012, lia as linhas sem lock e podia ser furada por duas transações concorrentes (NOVA-112). A correção não tocou em scope-ceiling.sql: ela é o arquivo novo scope-ceiling-locks.sql, carregado pela migration nova 0017_authorization-scope-ceiling-locks, que faz CREATE OR REPLACE das funções com as mesmas assinaturas. Detalhes em Teto de escopo.