Tag: ef-core

The EF Core version of the SQL Server provider in your startup project decides it: EF Core 7 and earlier scaffold date as DateTime, EF Core 8 through 11 scaffold it as DateOnly. Here is the type mapping that makes the call, measured output from EF Core 7, 8, 10, and 11 RC 2, and the two ways to get DateTime back without silently remapping the column to datetime2.

Pomelo 9.0.0 only allows EF Core Relational 9.0.x and has no EF Core 10 build. Keep every EF Core package on 9.0.x, or switch to Microting.EntityFrameworkCore.MySql 10.0.x. Suppressing the warning crashes at startup.

The tool package targets a newer .NET than the SDK running the install, or it is not a .NET tool at all. Use a newer SDK, pin a tool version with a compatible tools folder, or force --framework.

Use DbSet.Local.FindEntry(key) to ask the change tracker whether an entity with a given key is tracked, without a database round trip or a scan. Why Entry(entity).State lies for this question, why Find queries, and a tested AttachOrMerge helper for EF Core 10.

A compiled model is generated C# that recreates your EF Core model without running OnModelCreating. Measured on EF Core 11 RC1: model load drops from 714 ms to 215 ms at 500 entities, but the MSBuild route (which replaced EFOptimizeContext) is slower, stale models fail silently, and query filters block generation.

A shadow property is a column EF Core tracks without a matching CLR property. Here is why EF Core 11 creates them (missing FK properties, misnamed FKs, type mismatches, split relationships), how to spot the BlogId1 kind in a migration, how to fix each cause, and how to use shadow properties on purpose.

AddDbContextPool hands out one scoped DbContext per DI scope, so it cannot run two queries at once. AddDbContextFactory and AddPooledDbContextFactory give you a context per call, which is what parallel queries need. Measured on EF Core 11 RC 1: the pooled factory creates a context in 342 ns and 40 B versus 17 us and 44 KB.

After you delete the Migrations folder and scaffold a new InitialCreate, EF Core does not know your tables exist. Drop a dev database, or record the new migration in __EFMigrationsHistory without running it.

A SET statement run once is wiped by DISCARD ALL the moment Npgsql returns the connection to its pool. Put search_path and statement_timeout in the startup packet with the Search Path and Options connection string keywords, fall back to ALTER ROLE or a ConnectionOpened interceptor, and know why UsePhysicalConnectionInitializer silently loses its SET.

EF.Constant inlines a captured value as a SQL literal, EF.Parameter turns a literal into a SQL parameter. Keep EF Core's defaults, use EF.Parameter to stop dynamically built expression trees from recompiling on every call, and use EF.Constant only for a value with a handful of distinct values whose data is skewed enough to need its own plan.