#!/bin/sh
#
# O que `orm:schema-tool:update --force` destruiria hoje.
#
# POR QUE ISTO EXISTE. O D17 registrou, e o roadmap repetiu, que "os comandos
# destrutivos cairam de 114 para 0". O que caiu a zero foram os
# `ADD UNIQUE INDEX` -- que era o defeito do D17. A generalizacao para "nada
# destroi dados" nunca foi verificada, e era falsa: o `schema-tool` continua
# propondo comandos que apagam coluna. Eram QUATRO, e tres delas tem conteudo.
# Um dos quatro, `logradouros DROP tipo`, estava nomeado como exemplo no proprio
# texto do D17 -- a frase contradizia a pagina onde estava escrita.
#
# A contagem errada durou dias porque nada a conferia. Agora confere.
#
# LINHA DE BASE BAIXADA DE 4 PARA 3 EM 31/08/2026, e o motivo importa: a coluna
# `logradouros.tipo` NAO saiu do banco -- ela foi MAPEADA na entidade, entao o
# `schema-tool` parou de querer apaga-la. Foi este roteiro que exigiu a
# explicacao, ao dizer "sao menos que a linha de base" e mandar ler antes de
# comemorar. Estava certo em exigir: um numero que cai pode ser conserto ou
# pode ser alguem mapeando o que era para sumir. Neste caso foi conserto -- a
# coluna e `int NOT NULL` sem padrao, e sem mapeamento nenhum INSERT passava.
#
# LINHA DE BASE SUBIDA DE 3 PARA 4 EM 09/09/2026, e este caso e o INVERSO do
# anterior: la, MAPEAR uma coluna fez a queda sumir; aqui, DESMAPEAR uma fez
# uma queda aparecer -- de proposito. `unidades.iframe_bi` guardava a URL do
# Power BI, que saiu do sistema por decisao do dono (D9). O mapeamento saiu em
# 09/09/2026; a coluna continua no banco.
#
# ENTAO A CONTAGEM SO VOLTA A 3 QUANDO A COLUNA SAIR DE VERDADE, e isso e um
# ALTER em producao -- que este projeto nao faz por ora, por decisao do dono.
# Ate la a queda proposta e real e esta contada, que e o unico jeito honesto:
# marca que mente e pior que marca nenhuma.
#
# O QUE ELE NAO E: nao e permissao para rodar `--force`. NUNCA rodar `--force`
# contra banco com dados. Este roteiro so mantem honesta a contagem do que
# aconteceria.
#
# Uso:
#     sh scripts/conferir-schema-tool.sh

set -e

# LINHA DE BASE SUBIDA DE 4 PARA 6 EM 12/10/2026, e e o caso de 09/09 outra
# vez: coluna no banco sem mapeamento, de proposito. `cupons_clientes.desconto`
# e `cupons_clientes.produto_oferecido` (D271) entraram na copia local pela
# resposta 83 do dono, e a entidade `CupomCliente` nao as mapeia: a base do
# teste do BVIP so as ganha na proxima copia exportada, e la, mapeadas, toda
# leitura de cupom daria "Unknown column" (D473). O codigo as le e as grava
# pela conexao, e pergunta antes se elas existem. Mapeadas as duas, a contagem
# desce 2 -- e o conserto do D473, depois da exportacao.
#
# LINHA DE BASE SUBIDA DE 6 PARA 7 NO MESMO DIA, pelo mesmo motivo:
# `vendas_produtos.pacote_recusado` (D453, a resposta 80 do dono), o "Usar pacote:
# Nao" do PDV antigo gravado no item, entrou na copia local pela regra da resposta
# 83, e a entidade `VendaProduto` nao a mapeia -- mapeada, toda leitura de item de
# venda daria "Unknown column" na base do teste do BVIP. O codigo a le e a grava
# pela conexao (`VendaProdutoRepository`), depois de perguntar se ela existe. A
# queda proposta apagaria 3.264.661 zeros na copia, e o "Nao" de cada item gravado
# depois. Mapeada ela, desce 1; com as tres mapeadas, a contagem volta a 4 (o
# D473).
#
# LINHA DE BASE BAIXADA DE 7 PARA 6 NO MESMO DIA, e e o caso de 31/08 outra vez:
# MAPEAR uma coluna fez a queda sumir, e de proposito. `usuarios_acessos.local`
# (D76, a resposta 104 do dono) disse "web" ate 13/11/2025 e ficou vazia depois,
# porque a entidade nao a mapeava; agora `UsuarioAcesso` a mapeia e grava como a
# pessoa entrou (`senha`, `cookie` ou `assumida:<id>`). A coluna ja existia nos
# dois bancos e na producao, com o mesmo tipo e o mesmo padrao: o `schema-tool`
# nao propoe mudanca nenhuma nela (conferido no `--dump-sql`). Com as tres do
# D473 mapeadas, a contagem desce a 3.
#
# LINHA DE BASE SUBIDA DE 6 PARA 14 EM 13/10/2026, e e o caso de 12/10 outra vez:
# as oito colunas de Contas a Pagar (`migracao-saidas-motivos-e-autores.sql`; o
# D205, o D207 e o D199, as respostas 139, 140 e 18 do dono) entraram na copia
# local pela regra da resposta 83, e as entidades `Saida`, `SaidaParcela` e
# `SaidaParcelaPagamento` nao as mapeiam -- mapeadas, toda leitura de despesa,
# parcela e pagamento daria "Unknown column" na base do teste do BVIP. O codigo as
# le e as grava pela conexao (os tres repositorios), depois de perguntar se elas
# existem. A queda proposta apagaria o motivo e o autor de cada estorno, exclusao e
# quitacao sem pagamento gravados depois. Mapeadas as oito, desce 8; com as onze do
# D473 mapeadas, a contagem desce a 3.
#
# LINHA DE BASE SUBIDA DE 14 PARA 17 EM 21/10/2026, e e o caso de 12/10 outra vez:
# as tres colunas da regra do cupom de sorteio (`migracao-sorteios-regra-do-cupom.sql`;
# o D561, o pedido do dono na fatia SORTEIOS-CADASTRO) -- `sorteios.regra_cupom`,
# `sorteios.valor_cupom` e `sorteios_vendas.numero` -- entraram na copia local pela
# regra da resposta 83, e as entidades `Sorteio` e `SorteioVenda` nao as mapeiam --
# mapeadas, toda leitura de sorteio e de cupom daria "Unknown column" na base do teste
# do BVIP. O codigo as le e as grava pela conexao (`SorteioRepository` e
# `SorteioVendaRepository`), depois de perguntar se elas existem. A queda proposta
# apagaria a regra de cada sorteio e o numero de cada cupom -- e a chave unica
# (sorteio, venda, numero) cairia com ela. Conferido no `--dump-sql`: as tres quedas
# sao das tres colunas, e nada mais mudou. Mapeadas as tres, desce 3 (o D473).
#
# LINHA DE BASE SUBIDA DE 17 PARA 22 EM 08/11/2026, e e o caso de 12/10 outra vez:
# as cinco colunas novas de `assistentes` (`migracao-assistentes-anthropic.sql`; a
# fatia 133, ASSISTENTES-PORTA-DO-CLAUDE) -- `instrucoes`, `modelo`, `esforco`,
# `limite_de_tokens` e `pagina_publica` -- entraram na copia local pela regra da
# resposta 83, e a entidade `Assistente` nao as mapeia: mapeadas, toda leitura de
# assistente daria "Unknown column" na base do teste do BVIP. Quem as le e o
# `ConversaDoAssistenteService`, pela conexao, depois de perguntar se elas existem. A
# queda proposta apagaria as instrucoes de cada assistente. Conferido no `--dump-sql`:
# as cinco quedas sao das cinco colunas (e o indice unico da pagina, um DROP INDEX, com
# elas); as quatro tabelas novas, sem entidade, nao aparecem no `--dump-sql` (nenhum
# DROP TABLE nele, como a `confirmacoes`).
#
# A linha de base medida em 30/08/2026. Sobe so quando alguem CONFERIR que o
# comando novo e inofensivo; desce quando a coluna sai do banco de verdade.
ESPERADO=22

SAIDA=$(docker compose exec -T app vendor/bin/doctrine-module orm:schema-tool:update --dump-sql 2>/dev/null)

# `DROP` seguido de nome minusculo e queda de COLUNA. `DROP FOREIGN KEY` e
# `DROP INDEX` vem em maiusculas e nao casam -- e nao perdem dado; coluna perde.
#
# A classe traz digito de proposito: a primeira versao usava `[a-z_]` e cortava
# `senha_php83` em `senha_php`. Nome truncado num relatorio de coisa apagada e
# pior que nenhum relatorio.
#
# TODA CLAUSULA DO `ALTER`, e nao so a primeira (12/10/2026, D474). O
# `schema-tool` junta as quedas de uma tabela num `ALTER` so -- `ALTER TABLE
# cupons_clientes DROP produto_oferecido, DROP desconto, CHANGE ...` --, e a
# versao anterior lia so o `DROP` colado no `ALTER TABLE`: contava uma coluna
# onde ele apagaria duas. Medido na copia com as duas do cupom do dia: 5, e nao
# 6. Agora cada clausula, separada por virgula, e lida; a virgula de dentro de
# um tipo (`NUMERIC(10, 2)`) parte uma clausula `CHANGE`, e nenhum dos pedacos
# comeca por `DROP`.
QUEDAS=$(printf '%s\n' "$SAIDA" \
    | tr -d '\r' \
    | sed -nE 's/^ALTER TABLE ([a-z_0-9]+) (.*)$/\1 \2/p' \
    | awk '{
        tabela = $1
        sub(/^[^ ]+ /, "")
        n = split($0, clausulas, /, */)
        for (i = 1; i <= n; i++) {
            if (match(clausulas[i], /^DROP [a-z_0-9]+/)) {
                print tabela "." substr(clausulas[i], 6, RLENGTH - 5)
            }
        }
    }' \
    | sort -u)

if [ -z "$QUEDAS" ]; then
    N=0
else
    N=$(printf '%s\n' "$QUEDAS" | wc -l | tr -d ' ')
fi

TOTAL=$(printf '%s\n' "$SAIDA" | grep -cE '^(ALTER|CREATE|DROP)' || true)

echo ""
echo "O QUE O schema-tool DESTRUIRIA  (D17)"
echo "=============================================================================="
echo ""
echo "  comandos propostos ao todo: $TOTAL"
echo "  que APAGAM coluna:          $N   (linha de base: $ESPERADO)"
echo ""

if [ -n "$QUEDAS" ]; then
    printf '%s\n' "$QUEDAS" | sed 's/^/      /'
    echo ""
fi

if [ "$N" -gt "$ESPERADO" ]; then
    echo "  APARECEU QUEDA DE COLUNA NOVA."
    echo ""
    echo "  Alguma anotacao deixou de mapear uma coluna que existe no banco, ou uma"
    echo "  coluna nova entrou no banco sem entrar no mapeamento. Descubra qual antes"
    echo "  de mexer na linha de base."
    exit 1
fi

if [ "$N" -lt "$ESPERADO" ]; then
    echo "  SAO MENOS QUE A LINHA DE BASE."
    echo ""
    echo "  Se uma coluna saiu do banco de verdade, baixe ESPERADO neste roteiro e"
    echo "  atualize a tabela do D17. Se nao saiu, alguem mapeou uma coluna que era"
    echo "  para sumir -- e isso merece leitura antes de comemorar."
    exit 1
fi

echo "  Igual a linha de base. NUNCA rodar --force: sao 2.514.254 valores."
echo ""