Site Local

Portal de notícias de tecnologia

Django 6.1 ataca o problema N+1, leva a exclusão em cascata ao banco e prepara a numeração por ano

A versão de 5/8 aceita Python 3.12 a 3.14 e deixa de suportar PostgreSQL 14 e MySQL anterior ao 8.4. A próxima versão já se chamará Django 2028.

Django 6.1 ataca o problema N+1, leva a exclusão em cascata ao banco e prepara a numeração por ano

O projeto Django lançou em 5 de agosto de 2026 a versão 6.1 do framework web em Python. Segundo o anúncio oficial, os destaques são os modos de busca para campos de modelos, opções de exclusão executadas no próprio banco de dados para ForeignKey.on_delete e configurações de e-mail em formato de dicionário. As notas de lançamento informam suporte a Python 3.12, 3.13 e 3.14.

O que há de novo

Os modos de busca (fetch modes) controlam o que o ORM faz quando o código acessa um campo que ainda não foi carregado. São três: FETCH_ONE, o padrão e comportamento atual, busca o campo só para a instância em uso; FETCH_PEERS busca o campo para todas as instâncias vindas do mesmo QuerySet, como um prefetch_related() sob demanda, e segundo as notas reduz a maioria dos casos do problema de consultas N+1 a duas consultas; FETCH_RAISE lança a exceção FieldFetchBlocked, útil para impedir consultas acidentais em trechos críticos. O modo é escolhido com QuerySet.fetch_mode().

O on_delete ganhou as opções DB_CASCADE, DB_SET_NULL e DB_SET_DEFAULT, que usam a cláusula SQL ON DELETE e não precisam carregar os objetos antes de apagar. A documentação avisa que, por isso, DB_CASCADE não dispara os sinais pre_delete e post_delete, um ponto de atenção para quem depende deles. A nova configuração MAILERS permite definir vários backends de e-mail com opções diferentes, como já acontece com CACHES e DATABASES. As configurações antigas continuam funcionando, mas emitem avisos de obsolescência.

Bancos de dados e compatibilidade

  • PostgreSQL 14 deixa de ser suportado; o mínimo passa a ser o 15.
  • MySQL anterior ao 8.4 sai; o mínimo é o 8.4.
  • MariaDB anterior ao 10.11 sai; o mínimo é o 10.11.
  • A versão mínima do SQLite sobe de 3.31.0 para 3.37.0.
  • A configuração de transição SIGNED_COOKIE_LEGACY_SALT_FALLBACK passa a ter False como padrão.

Calendário de suporte e mudança de numeração

O suporte principal ao 6.1 deve terminar em abril de 2027, e o estendido, em dezembro de 2027. Com o lançamento, o Django 6.0 saiu do suporte principal e recebe só correções de segurança e de perda de dados até abril de 2027. Seguindo a proposta DEP 20, as versões que seriam o Django 7.0 e o 7.1 passam a se chamar Django 2028 e 2029, e as classes de aviso foram renomeadas: RemovedInDjango70Warning virou RemovedInDjango2028Warning. Quem filtra esses avisos pelo nome precisa ajustar o código.

A LWN noticiou em 10/8 que o projeto aprovou também um ciclo anual de lançamentos: cada versão terá três anos de suporte, um de correções gerais e dois de segurança e perda de dados, e o rótulo LTS será aposentado. Segundo a publicação, a mudança vale a partir do Django 2028, previsto para janeiro de 2028. Na prática, quem desenvolve poderá atualizar um ano por vez, sem ter de pular duas versões de uma só vez ao fim de cada LTS.

Fontes

Imagem destacada: ilustração gerada por computador, sem valor documental.

Deixe comentário

Seu endereço de e-mail não será publicado. Os campos necessários são marcados com *.

Fique por dentro

As principais notícias de tecnologia, todos os dias

Siga o portal nas redes sociais e acompanhe IA, cibersegurança, cloud, hardware e o mercado de tecnologia em primeira mão.