Experimental support for the Azure SQL JSON type#34401
Conversation
ajcvickers
force-pushed
the
JsonButNotTooMuch
branch
5 times, most recently
from
b6250a2 to
b35704a
Compare
| { | ||
| Value = value, | ||
| TypeMapping = parameters.TypeMapping is SqlServerJsonElementTypeMapping | ||
| ? SqlServerStringTypeMapping.UnicodeDefault |
There was a problem hiding this comment.
This isn't great, but I think can be cleaned up when we tackle the Element mapping work.
|
@roji This is ready for review from the EF side. |
roji
left a comment
roji
left a comment
There was a problem hiding this comment.
Here are the last comments - looks really good overall.
@AndriySvyryd may be interested in taking a look for the model building (and possibly update pipeline) aspects.
| /// any release. You should only use it directly in your code with extreme caution and knowing that | ||
| /// doing so can result in application failures when updating to a new Entity Framework Core release. | ||
| /// </summary> | ||
| public static SqlServerStringTypeMapping JsonTypeDefault { get; } = new("json", sqlDbType: (SqlDbType)35); |
There was a problem hiding this comment.
I'm wondering whether it makes sense to have a separate SqlServerJsonTypeMapping that isn't SqlServerStringTypeMapping... It's a different database type with a different SqlDbType, SqlServerStringTypeMapping is already a bit complex with all the different facets, and a different type would allow for easier pattern matching e.g. in the query pipeline...
There was a problem hiding this comment.
I did this at first, but the interactions with the element type mapping make it difficult. We need to remove (fix) the element type mapping and then see where this lands.
There was a problem hiding this comment.
@roji I was thinking about this again last night, while listening to Indian Rap Metal, and I think the question is do we want to allow a SqlServerStringTypeMapping with a store type of "json" to be treated as if it points to the native JSON type (even if a different type mapping exists), as if it's a string type with a custom database name--such as "text" for example, or be not allowed--such as "int"? I suspect that the answer is it should not be allowed, because if its a JSON type, we shouldn't treat it as a string. If you agree, I can try that now (that is, introduce a new type mapping and validate that a string type mapping is never used for the "json" type), and if it gets tricky due to the element mapping, then I'll add it in the issue for replacing the element mapping.
There was a problem hiding this comment.
Yeah, I think that makes sense to me...
I may be missing something but... I'm not sure how important it is to guard against SqlServerStringTypeMapping with json (or int) - how would a user actually make that happen, assuming we never return it from SqlServerTypeMappingSource? In other words, if the type mapping source returns the specific SqlServerJsonTypeMapping whenever the column type is json, that seems sufficient...
But no objection to also checking/blocking or whatever... Anything here is fine I think.
There was a problem hiding this comment.
@roji Agreed that it is somewhat unrealistic that an application would explicitly create a type mapping. Right now, we internally get type mappings not through the source. So it's probably more of an internal concern than an application facing concern. My main concern is that we don't sometimes use string type mappings, and sometimes not.
There was a problem hiding this comment.
Understood - makes sense then as a sanity check!
ajcvickers
force-pushed
the
JsonButNotTooMuch
branch
2 times, most recently
from
ee9d4b2 to
ee8ffd5
Compare
|
Add tests to |
roji
left a comment
roji
left a comment
There was a problem hiding this comment.
OK to merge from my side - but see remaining minor nits and Andriy's comments.
|
|
||
| namespace Microsoft.EntityFrameworkCore.Query; | ||
|
|
||
| [SqlServerCondition(SqlServerCondition.SupportsFunctions2022 | SqlServerCondition.SupportsJsonType)] |
There was a problem hiding this comment.
Is the SupportsFunctions2022 still necessary now that we have SupportsJsonType?
There was a problem hiding this comment.
Define "necessary". We still have tests that require this but don't require the JSON type. We could stop running those tests...
There was a problem hiding this comment.
Well, the regular PrimitiveCollectionsQuerySqlServerTest (without the JSON type) doesn't have that condition, so why does the JSON version of that test suite need it?
There was a problem hiding this comment.
The 160 version of those tests does.
Here's where it is used:
There was a problem hiding this comment.
Basically, I made the JSON type tests for primitive collections require SQL Server 160. But that doesn't mean that all the tests that need 160 (or these functions) require the JSON type.
So, we could collapse, but if we do it before the JSON type is supported anyway, then we stop running all those tests.
Fixes #28452 Fixes #32150 Remaining work: - Test reverse engineering from an existing database - Output a warning when the native JSON type is used - Replace the ToJson overload with HasColumnType() - Move the type mapping visitation to another visitor Known issues: - Various issues communicated with the SQL team--see TODO:SQLJSON - Testing is disabled until we have an appropriate server and driver to test against
ajcvickers
force-pushed
the
JsonButNotTooMuch
branch
from
ee8ffd5 to
e18f664
Compare
ajcvickers
force-pushed
the
JsonButNotTooMuch
branch
from
e18f664 to
ca50eb6
Compare
Can you be more specific about what you want testing here? |
ajcvickers
force-pushed
the
JsonButNotTooMuch
branch
from
704fc29 to
80d794c
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Tests that validate that the new json type mapping for owned types is preserved in the snapshot and in the compiled model. |
|
Also add a test that validates that the appropriate migration operation is generated when the column type of an owned type mapped to json is changed |
3 participants
Fixes #28452
Fixes #32150
Remaining work:
Known issues: