Repository navigation
Read vector dimensions when scaffolding SQL Server databases below compatibility level 170 - #39162
Merged
AndriySvyryd merged 2 commits intoOct 8, 2026
Merged
Conversation
…mpatibility level 170 The vector type is available under all database compatibility levels, but the scaffolder only read sys.columns.vector_dimensions when the compatibility level was 170 or higher. On a SQL Server 2025 or Azure SQL database at a lower level, vector columns were scaffolded as vector(0), which the type mapping then rejected with "Vector properties require a positive size". Read the dimensions whenever the server has the vector type instead. Fixes dotnet#38763
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Setup failures can leave the shared test database at compatibility level 160.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Fixes SQL Server vector scaffolding below compatibility level 170 by detecting type availability rather than database compatibility.
Changes:
- Uses loaded type metadata to decide whether to read vector dimensions.
- Adds regression coverage at compatibility level 160.
| File | Description |
|---|---|
| test/EFCore.SqlServer.FunctionalTests/Scaffolding/SqlServerDatabaseModelFactoryTest.cs | Verifies vector dimensions and mapped size at level 160. |
| src/EFCore.SqlServer/Scaffolding/Internal/SqlServerDatabaseModelFactory.cs | Gates dimension reads on vector type availability. |
…f setup fails The fixture database is shared, so the level is now restored in an outer finally instead of in the table cleanup script, which is skipped when the setup itself fails.
AndriySvyryd
approved these changes
Oct 8, 2026
AndriySvyryd
left a comment
AndriySvyryd
left a comment
Member
There was a problem hiding this comment.
Thanks for your contribution!
1 of 4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #38763
The SQL Server
vectortype is available under all database compatibility levels, but the scaffolder only readsys.columns.vector_dimensionswhen the database was at compatibility level 170 or higher. On SQL Server 2025 or Azure SQL databases at a lower level (for example a database upgraded from SQL Server 2022, which stays at 160), vector columns were scaffolded asvector(0), and scaffolding then failed with "Vector properties require a positive size (number of dimensions)".The dimensions are now read whenever the server has the
vectortype, based on the type aliases the factory already loads fromsys.types, instead of the compatibility level. No extra query is added.Added
Vector_type_with_compatibility_level_below_170, which lowers the test database to compatibility level 160, scaffolds avector(3)column and checks the store type and the mapped size. It fails withvector(0)on main. Like the existingVector_typetest, it runs only whereIsVectorTypeSupportedis true.