Remove lookup of JsonTypeMapping via JsonElement #32192
Comments
|
dummy clr type sounds good to me |
|
This is unfortunately more than a cleanup - the current hacky way of doing things in EFCore.PG unfortunately doesn't take care of literal generation, which is necessary e.g. when adding a column to an existing table (for the default value). There, CSharpHelper.UnknownLiteral is used, which just does a type mapping lookup based on the CLR type (JsonElement), retrieving the owned JSON type mapping rather than the non-owned one. See npgsql/efcore.pg#3107 (comment) for more details. |
|
This also blocks being able to use ToJson() with the PostgreSQL non-default @maumar do you think we can do this for 10? |
maumar
added a commit
that referenced
this issue
Mar 14, 2025
When adding support for JSON mapped types, we decided to use JsonElement as a CLR type marker for JsonTypeMapping. This decision was in hindsight incorrect, it makes it hard for providers that actually support weak-typed json (npgsql) and throws cryptic exception (No coercion operator is defined between types 'System.IO.MemoryStream' and 'System.Text.Json.JsonElement) for providers that don't support it, when customers try to do it regardless. Fix is to create a dummy type and use that instead, so JsonElement is no longer recognized by base EFCore. Fixes #32192 also fixes #34752
maumar
added a commit
that referenced
this issue
Mar 14, 2025
When adding support for JSON mapped types, we decided to use JsonElement as a CLR type marker for JsonTypeMapping. This decision was in hindsight incorrect, it makes it hard for providers that actually support weak-typed json (npgsql) and throws cryptic exception (No coercion operator is defined between types 'System.IO.MemoryStream' and 'System.Text.Json.JsonElement) for providers that don't support it, when customers try to do it regardless. Fix is to create a dummy type and use that instead, so JsonElement is no longer recognized by base EFCore. Fixes #32192 also fixes #34752
maumar
added a commit
that referenced
this issue
Mar 14, 2025
When adding support for JSON mapped types, we decided to use JsonElement as a CLR type marker for JsonTypeMapping. This decision was in hindsight incorrect, it makes it hard for providers that actually support weak-typed json (npgsql) and throws cryptic exception (No coercion operator is defined between types 'System.IO.MemoryStream' and 'System.Text.Json.JsonElement) for providers that don't support it, when customers try to do it regardless. Fix is to create a dummy type and use that instead, so JsonElement is no longer recognized by base EFCore. Fixes #32192 also fixes #34752
maumar
added a commit
that referenced
this issue
Mar 14, 2025
When adding support for JSON mapped types, we decided to use JsonElement as a CLR type marker for JsonTypeMapping. This decision was in hindsight incorrect, it makes it hard for providers that actually support weak-typed json (npgsql) and throws cryptic exception (No coercion operator is defined between types 'System.IO.MemoryStream' and 'System.Text.Json.JsonElement) for providers that don't support it, when customers try to do it regardless. Fix is to create a dummy type and use that instead, so JsonElement is no longer recognized by base EFCore. Fixes #32192 also fixes #34752
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In order to find the provider's JsonTypeMapping, our code currently does a standard lookup with CLR type JsonElement (as a sort of special value). The problem is that some provider's actually do support JsonElement as a real property CLR type; in addition, if a user defines a JsonElement property on some entity type, this type mapping will be return, and things will likely fail in some unpredictable way.
We should find another way to look up the JsonTypeMapping, e.g. define some special CLR type instead of JsonElement that could be used, or introduce a new API or something.
/cc @maumar
The text was updated successfully, but these errors were encountered: