-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Bring JSON type out of experimental status #36442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
50b7c3d to
8812300
Compare
test/EFCore.SqlServer.FunctionalTests/Query/AdHocJsonQuerySqlServerTestBase.cs
Show resolved
Hide resolved
| // When testing against SQL Server 2025 or later, set the compatibility level to 170 to use the json type instead of nvarchar(max). | ||
| public override DbContextOptionsBuilder AddOptions(DbContextOptionsBuilder builder) | ||
| => UsingJsonType | ||
| ? builder.UseSqlServer(o => o.UseCompatibilityLevel(170)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note the two different testing strategies:
- These relationship query tests use the same suites to test both new and old SQL Server versions (with different translations), varying the compatibility level based on the actual server being targeted. This means that for full coverage, our CI must run both the newest and the oldest supported SQL Server version.
- Baselines can assert on the different translations (see just below). This is really nice for seeing the differences.
- Less duplication, just one test suite covers both translations (assuming we run against the different versions in CI).
- The alternative is done in PrimitiveCollectionsQuerySqlServerJsonTypeTest, where there's a separate test suite only for the new translations, which gets skipped if the targeted SQL Server doesn't support the feature.
- This causes lots of duplication and is less manageable.
| typeof(string), | ||
| typeMappingSource.FindMapping(typeof(string))!)) | ||
| : base.Visit(expression); | ||
| // The SQL Server json type cannot be compared ("The JSON data type cannot be compared or sorted, except when using the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to confirm this in design.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design decision: we'll go ahead with allowing comparison of JSON-mapped complex types by adding this cast to nvarchar(max):
- This isn't any worse than the already-supported comparison of
nvarchar(max)-mapped types. - As long as EF is used to read/write the columns, everything works.
- We don't want the new
jsonsupport to be inferior to the worstnvarchar(max)mapping option.
| jsonScalar.IsNullable); | ||
| } | ||
|
|
||
| case SqlServerOpenJsonExpression openJsonExpression: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed that this cast is no longer needed - OPENJSON can just directly accept the json data type.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
* Remove experimental warning * Remove conversion to nvarchar(max) within OPENJSON * Add conversions to nvarchar(max) when comparing json (not natively supported) * Use json type in complex JSON query tests when targeting newer versions of SQL Server * Various test tweaks and cleanup Closes dotnet#36024
Closes #36024
/cc @artl93