EF Core 11: novidades e mudanças do .NET 11 Preview 7

Tradução de int.Parse no SQL Server

Os métodos byte.Parse, short.Parse, int.Parse, long.Parse, decimal.Parse, double.Parse e float.Parse agora viram CAST no SQL Server. A mudança vale para as sobrecargas simples que recebem apenas uma string.

Antes, essas chamadas caíam em avaliação no cliente. Com isso, o EF Core trazia dados adicionais para a memória antes de aplicar o filtro.

var rows = await context.BasicTypes
    .Where(o => int.Parse(Convert.ToString(o.Int)) == 12)
    .ToListAsync();

O SQL gerado agora resolve a conversão no servidor.

SELECT ...
FROM [BasicTypesEntities] AS [b]
WHERE CAST(CONVERT(nvarchar(max), [b].[Int]) AS int) = 12

Convém observar que a tradução resolve um problema de correção, e não de desempenho. Um CAST sobre coluna no WHERE continua atrapalhando o uso de índices, então filtre pelo tipo nativo sempre que possível.

Agregados de GroupBy sobre navegações no EF Core 11

Este é provavelmente o item de maior impacto prático da preview. Um agregado como g => g.Max(o => o.Customer.Region), que atravessa uma navegação de referência, gerava uma subconsulta correlacionada.

O efeito era severo, porque a subconsulta reexaminava a fonte de dados uma vez por grupo. Na prática, tratava-se de uma regressão introduzida no EF Core 7.

No EF Core 11, a expansão de navegações eleva a navegação para a fonte anterior ao GroupBy. Assim, o agregado volta ao formato de junção única seguida de agrupamento.

var byEmployee = await context.Orders
    .GroupBy(o => o.EmployeeId)
    .Select(g => new { EmployeeId = g.Key, TopRegion = g.Max(o => o.Customer.Region) })
    .ToListAsync();

O contraste entre o SQL antigo e o novo evidencia a diferença de custo.

-- Antes (EF Core 7 a 10): reexame correlacionado por grupo
SELECT (
    SELECT MAX([c].[Region])
    FROM [Orders] AS [o0]
    LEFT JOIN [Customers] AS [c] ON [o0].[CustomerId] = [c].[CustomerId]
    WHERE [o].[EmployeeId] = [o0].[EmployeeId]) AS [TopRegion], ...
FROM [Orders] AS [o]
GROUP BY [o].[EmployeeId]

-- Depois: LEFT JOIN único seguido de GROUP BY
SELECT [o].[EmployeeId], MAX([c].[Region]) AS [TopRegion]
FROM [Orders] AS [o]
LEFT JOIN [Customers] AS [c] ON [o].[CustomerId] = [c].[CustomerId]
GROUP BY [o].[EmployeeId]

Dois detalhes merecem atenção de quem revisa planos de execução. Primeiro, múltiplos agregados sobre a mesma navegação reutilizam uma única junção.

Além disso, navegações obrigatórias passam a usar INNER JOIN em vez do LEFT JOIN incondicional do GroupJoin anterior. Com isso, o otimizador descarta linhas mais cedo e considera novas estratégias de junção.

Composição sobre GroupBy seguido de First

Consultas que reduzem cada grupo a uma entidade com First, Single ou Last falhavam ao continuar a composição. O erro surgia ao projetar uma navegação, filtrar ou ordenar depois da redução.

A correção atua em duas camadas. Primeiro, a expansão de navegações guarda um instantâneo do seletor de elemento do grupo.

Em seguida, o vinculador de projeção relacional rebaixa subconsultas de resultado único sob demanda. Antes, isso só acontecia ao final da tradução.

var latestPerOrder = await context.TimeSheets
    .GroupBy(t => t.OrderId)
    .Select(g => g.OrderBy(x => x.Id).First())
    .OrderBy(t => t.Order.Number)
    .ToListAsync();

Esse padrão aparece com frequência em relatórios operacionais. Por exemplo, buscar o registro mais recente por chave e ordenar por um campo relacionado é comum em sistemas de auditoria.

Reuso de subconsulta no EF Core 11

Às vezes uma projeção lê vários membros da mesma subconsulta correlacionada de resultado único. Nesse caso, o EF Core 11 reescreve a projeção em um SelectMany, e os membros vêm de uma única junção.

As formas cobertas incluem First, Single, Last e ElementAt, além das variantes OrDefault e com predicado. Contudo, trata-se de uma solução intermediária enquanto o time reformula o mecanismo de seletores pendentes.

Acesso a membros de ValueTuple e Tuple

Acessar um item de um ValueTuple ou Tuple projetado antes na consulta falhava na tradução. Um caso concreto é uma chave de GroupBy do tipo ValueTuple<int, int> usada depois em uma junção.

A causa raiz é sutil. O compilador só popula NewExpression.Members para tipos anônimos, então o visitante de expressões ficava sem o mapeamento entre construtor e membros.

Agora o ReplacingExpressionVisitor resolve esses membros pelo nome do parâmetro do construtor. A cobertura inclui aridades de um a oito, inclusive a forma aninhada via Rest.

var joined = await context.Orders
    .GroupBy(o => new ValueTuple<int, int>(o.CustomerId, o.EmployeeId))
    .Join(
        context.Customers,
        g => g.Key.Item1,
        c => c.Id,
        (g, c) => new { c.Name, Count = g.Count() })
    .ToListAsync();

A restrição a esses dois tipos é deliberada. O mapeamento deles é um contrato fechado, enquanto classes e records arbitrários poderiam levar silenciosamente ao valor errado.

Projeções nulas em LEFT JOIN sem correspondência

Este item corrige uma exceção em um cenário legítimo. O problema surgia em um LEFT JOIN cujo lado interno projeta um tipo anônimo, um DTO ou um agregado de GroupBy.

Nas linhas sem correspondência, a consulta lançava InvalidOperationException. Na origem, o EF Core montava o objeto a partir de colunas nulas em vez de produzir null.

Entidades já tratavam esse caso pela verificação de nulidade nas colunas de chave. Agora a preview injeta uma coluna marcadora na subconsulta interna e condiciona a projeção a esse marcador.

var query = context.Owners
    .GroupJoin(
        context.Pets,
        o => o.Id,
        p => p.OwnerId,
        (o, ps) => new { o.Name, PetInfo = ps.Select(p => new { p.Name, p.Age }).FirstOrDefault() })
    // Antes lançava exceção para donos sem animais; agora PetInfo fica null.
    .ToListAsync();

O marcador também sobrevive a cenários compostos, como uma junção subsequente. Para structs, record structs e Nullable<T>, o resultado passa a ser default(T) em vez de exceção.

Novo materializador do Cosmos DB no EF Core 11

No EF Core 11, o provider do Cosmos DB materializa resultados com Utf8JsonReader. Além disso, some a limitação histórica de Distinct em projeções no cliente.

A propriedade de apoio __jObject deixa de existir. Ao mesmo tempo, o pipeline troca o Newtonsoft.Json pelo System.Text.Json, via CosmosStructuralTypeSerializer.

Duas mudanças de comportamento exigem atenção em migração. A primeira: AsNoTrackingWithIdentityResolution passa a exigir as chaves primárias em projeções de tipos pertencidos.

A segunda envolve ponto flutuante materializado em tipos de ponto fixo, que agora sofre truncamento em vez de arredondamento. Por exemplo, 0.75 agora vira 0, como em (int)0.75 no .NET.

Quem dependia do arredondamento anterior precisa aplicá-lo de forma explícita, tipicamente com Math.Round.

var result = await context.Products
    // Arredondamento explícito para manter o comportamento antigo
    .Select(p => (int)Math.Round((double)p.Quantity / (p.Quantity + 1)))
    .SingleAsync();

Cabe um alerta para quem opera em produção. Sem o __jObject, propriedades JSON não mapeadas se perdem na ida e volta, e a documentação classifica isso como alto impacto.

Requisições passam pela estratégia de execução

Dois caminhos que ignoravam a política de repetição agora passam por ela. Primeiro, a verificação de status da resposta de consulta ocorre dentro da estratégia de execução.

Assim, falhas transitórias durante a iteração de páginas ganham nova tentativa. Antes, elas chegavam direto ao chamador.

Falhas em lotes transacionais também mudam. Agora elas surgem como exceções repetíveis, inclusive nos lotes por chave de partição do SaveChanges.

O ganho de confiabilidade é relevante. Afinal, sistemas que dependem de repetição contra limitação de taxa perdem dois pontos cegos.

NoBuild no Package Manager Console do EF Core 11

No EF Core 11, os cmdlets Add-Migration e Update-Database aceitam o parâmetro -NoBuild. Ele pula a compilação, assim como dotnet ef migrations add --no-build já fazia.

Add-Migration InitialCreate -NoBuild
Update-Database -NoBuild

Há dois cenários claros de uso. O primeiro é o projeto já compilado, em que a recompilação é apenas custo.

O segundo envolve avisos de vulnerabilidade do NuGet, como NU1902, que bloqueariam o comando. Contudo, use o parâmetro só com o build atualizado.

Migrations bundle com Central Package Management

O comando dotnet ef migrations bundle falhava com NU1008 em soluções com gerenciamento centralizado de pacotes. A causa era uma PackageReference versionada que o projeto temporário sempre emitia.

Agora o projeto de bundle emite referências condicionais. Ou seja, sem CPM a referência leva versão, e com CPM ela usa o PackageVersion do Directory.Packages.props.

Caminhos de deps e runtimeconfig

A ferramenta dotnet ef montava os caminhos de --depsfile e --runtimeconfig a partir de AssemblyName. Isso quebrava projetos que combinam TargetName com ProjectDepsFileName.

Agora a ferramenta lê as propriedades MSBuild ProjectDepsFileName e ProjectRuntimeConfigFileName. Quando elas estão vazias, volta ao comportamento anterior.

Reordenação em transições de sequência TPC

Hierarquias TPC que consolidavam sequências em uma sequência compartilhada geravam migrações inválidas. O mesmo acontecia ao renomear essa sequência compartilhada.

O motivo era de ordenação, porque a sequência antiga sumia antes da reescrita dos valores padrão. A correção reorganiza essas operações.