Rails ganha cache de schema em JSON e nova tarefa herb:check para validar views
O resumo semanal do Rails traz cache de schema até 22x mais rápido em bases grandes, uma checagem estática para todos os templates ERB e correções importantes de introspecção no PostgreSQL e no Active Storage.
O boletim semanal do Rails (This Week in Rails, publicado por Emmanuel Hayford em 18 de setembro) costuma ser tratado como nota de rodapé, mas essa edição concentra mudanças que valem revisão: um formato novo de cache de schema com ganho de performance mensurado, uma tarefa de CLI para pegar erro de template antes do deploy, e três correções de bug que mexem com integridade de dados em produção. Todas as mudanças chegaram ao branch principal do Rails nesta semana, via trabalho de 29 contribuidores, e devem aparecer na próxima release ou em algum patch subsequente.
Cache de schema em JSON: quando o formato do arquivo vira gargalo
Ative Record sempre ofereceu duas formas de serializar o schema cache: YAML (legível, mais lento pra parsear) e Marshal (rápido, mas binário e acoplado à versão do Ruby↳Ruby3 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019Refatoração em RubyDev (Back & Front) · mai 20197 exemplos de linguagens de programação server-sideGestão Dev & TI · jun 2024Ver tudo em Dev (Back & Front) → que gerou o arquivo, o que trava em deploys com upgrade de runtime). Agora existe uma terceira opção: apontar config.active_record.schema_cache_path para um arquivo terminando em .json faz o Active Record dumpar e carregar o cache nesse formato.
O número que o post cita é concreto: numa aplicação de produção com 944 tabelas, o carregamento em JSON foi cerca de 22x mais rápido que em YAML. Isso importa porque o schema cache é lido no boot da aplicação (e em cada worker de deploy, cada job runner, cada teste que sobe o Rails do zero). Em monólitos grandes com centenas de tabelas, esse boot lento vira minutos acumulados em pipeline de CI, não segundos.
O trade-off aqui é pequeno: JSON não é binário nem acoplado a versão do Ruby como Marshal, então dá pra versionar o arquivo no repositório sem medo de quebrar entre ambientes diferentes, mas ainda assim é mais rápido de carregar que YAML. Para uma aplicação pequena, com trinta tabelas, a diferença de milissegundos não paga a atenção de trocar a config. Vale a troca quando o boot já é percebido como lento no dia a dia do time.
herb:check: lint estático para todo template ERB do projeto
A nova tarefa bin/rails herb:check compila cada template HTML+ERB da aplicação usando o parser Herb, passando pelos mesmos resolvers que o lookup de views usa em runtime, o que significa que variants, locales e view paths de engines também entram na varredura. Templates que o Herb rejeita aparecem listados com caminho e erro, e a tarefa retorna código de saída diferente de zero quando algo falha.
Na prática, isso é uma checagem que hoje só acontece de forma reativa: você só descobre que um .html.erb tem um erro de sintaxe quando alguém navega até aquela página específica (ou pior, quando um teste de sistema cobre por acidente aquela rota). Rodar herb:check no CI, antes do deploy, transforma esse erro em falha de build, no mesmo espírito de rodar rubocop ou brakeman como gate.
O limite é claro: o Herb valida sintaxe e estrutura do template, não lógica de negócio. Uma interpolação que renderiza nil sem quebrar, ou uma partial que existe mas recebe a variável errada, passa batido. É complemento de teste de sistema, não substituto, mas é um complemento barato, porque roda em segundos e não depende de banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → nem de fixtures.
PostgreSQL: dois bugs de introspecção que mexem com integridade
Dois ajustes no adapter de PostgreSQL merecem atenção de quem trabalha com schemas múltiplos ou índices cobertos.
O primeiro: métodos como indexes, foreign_keys, check_constraints, unique_constraints e exclusion_constraints resolviam um nome de tabela sem qualificação comparando contra todos os schemas do search path. Se dois schemas diferentes tinham uma tabela com o mesmo nome, o Active Record retornava índices e constraints das duas, um resultado errado e silencioso. Agora esses métodos resolvem o nome do mesmo jeito que ::regclass faz no Postgres, igual ao que já acontecia com primary_keys e table_options. Isso é relevante para quem usa multi-tenancy baseado em schema (Apartment, Scenic com schemas separados, ou setup manual) e nunca percebeu a inconsistência porque os nomes de tabela raramente colidem entre tenants, mas quando colidem, o dado que vinha de volta estava simplesmente errado.
O segundo bug é mais sutil e mais perigoso: pg_index.indkey inclui colunas não-chave adicionadas com INCLUDE em índices cobertos, então uma chave primária com índice INCLUDE aparecia como se tivesse colunas extras, e essas colunas extras não eram graváveis durante upsert em lote (upsert_all, insert_all). A correção passa a ler a chave primária de pg_constraint.conkey, a lista ordenada de colunas do próprio constraint, em vez de inferir do índice. Quem usa INCLUDE para otimizar índice de cobertura (padrão comum em tabelas de alto volume de leitura) e faz bulk upsert nessas tabelas estava potencialmente perdendo updates em colunas que o Active Record achava, erroneamente, que faziam parte da PK.
Active Storage: booting mais tolerante a ambiente inconsistente
Duas correções resolvem o mesmo tipo de dor: a aplicação Rails travando no boot por causa do libvips, mesmo quando o processador de imagem configurado nem usa libvips.
Antes, uma app com a gem ruby-vips instalada mas sem a biblioteca nativa libvips no sistema abortava a inicialização com um LoadError. Agora esse erro é tratado como
Fonte: Ruby on Rails Blog
Este artigo foi escrito por Bisneto Braga, colunista de back-end. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de back-end, arquétipo staff engineer/consultor poliglota: já manteve monolito PHP, app Rails e serviço Java em produção. Lema declarado na bio: linguagem é ferramenta, contexto é rei. Sem torcida — a opinião dele é sempre comparativa e pragmática.
