Repository navigation
EF tests: run queries and round trips against SQL Server #81
Description
The EF satellite's tests run queries and round trips on PostgreSQL (Npgsql) and SQLite, and SQL Server only for its model, built without a server (Directory.Packages.props, the EF test packages' comment; KeyGenerationTests). No test runs a query against SQL Server.
The EF Core README promises that .Value works in LINQ as it does in memory. SQL Server is where that is most likely to differ:
- Collation. The default collation is case-insensitive, so
Where(c => c.Code == code)andContains/StartsWithover a string value object can match rows that are not equal in memory, where string equality is ordinal. Ordering follows the collation too. - Precision.
datetime2anddecimal(p,s)round on write, asnumeric(p,s)does on PostgreSQL (KB-034). - Keys. Key generation is checked on the model only; an identity or sequence key over a value object is never inserted and read back.
Proposal
Add a SQL Server leg to the EF round-trip and query tests, on Testcontainers (Testcontainers.MsSql), over the existing KeyShapes and QueryShapes catalogues. Each difference it finds is either a fix or a pinned fact in design/knowledge/ with its test, cited from the EF README where it changes what a consumer sees.
Done when
- The EF tests run the query and round-trip shapes on SQL Server in CI (Linux runner; the container needs no Windows).
- Every difference from in-memory behaviour is fixed or recorded as a KB entry, and the README states the ones a consumer must know.
Activity
CaffeinatedCoder commentedon Oct 29, 2026
What the SQL Server leg found (PR #142), measured on Azure SQL Edge locally and on SQL Server 2022 in CI:
No difference needed a change in
src/. On SQL Server a value object answers as its wrapped type does, over the whole query catalogue (~10k cases) and the key catalogue (every shape × key kind, inserted and read back). The differences from memory are SQL Server's own, each pinned as a fact with a plain-EF test:==,IN,LIKE,ORDER BY).uniqueidentifierorders by its last group first.decimalwithout a precision isdecimal(18,2), read back at scale 2 (10.00) and rounded on write.timeholds less than a day. A longerTimeSpanis refused in a column, and silently read as another value from a JSON column (1.02:00:00→01:02:00).MAX/MINof abit.EF.Functions.Greatest/Leastonly from compatibility level 160. At 160, the value object's SQL is the wrapped type's.datetime2keeps every tick and reads aDateTimeback withKindUnspecified.The other differences from memory are relational, shared with SQLite: a null
.Valuethat throws in memory and is a NULL in SQL, and queries EF translates for neither. The EF README's new "On SQL Server" section states the ones a consumer meets.Two side notes:
Greatest/Leastcomparing strings by culture; it's ordinal now.TYPEKIT_MSSQL_IMAGE=mcr.microsoft.com/azure-sql-edge:latestruns it natively there (CONTRIBUTING).CaffeinatedCoder commentedon Oct 29, 2026
Done in #142, merged into
release/2.3.0(4ff49f5): the query and key catalogues run on SQL Server 2022 in CI's Linux leg; seven differences pinned as KB-048 to KB-054, the EF README's "On SQL Server" section states them; nothing insrc/needed a change.