Feat/net10: Fixes Owned JSON Entities and Adds Support for the new Complex Properties.

[r-Larch]

Hi @artiomchi ,

I saw your issue EF Core v10 release #186 and would like to help.

As I wrote the initial owned entity logic, I feel responsible for fixing it ;)

This PR fixes the problem with owned JSON entities and adds support for the new complex properties.

The problem with owned JSON entities:

• EF Core 10 removed the internal JSON serialization in GenerateProviderValueSqlLiteral.
• JSON serialization in EF Core happens over JsonValueReaderWriter, but there is no reusable code to serialize owned JSON INavigation entities.
• So I implemented the RelationalJsonHelper based on the public JSON helper for the new complex properties RelationalJsonUtilities and the json serialization logic for INavigation in ModificationCommand

Support for the new complex properties:

• Complex Properties are the new way to do Owned Entities and Owned JSON Entities.
• Now we have support and tests for complex properties and complex JSON properties.

I left some comments in the code:

1. I'm not very happy with having to implement the RelationalJsonHelper for JSON serialization, as I would like to reuse EF Core internals for it, but I could not find any useful public type for it. Maybe you have or can find a better idea?
2. The ProcessComplexProperty recursive function would be able to handle Complex table shared properties with a child complex property mapped to JSON, but EF Core does not currently support it and throws in OnModelCreating. Maybe we should be more cautious and also throw? What do you think? Allow nested complex properties mapped to JSON with the top complex property using table sharing dotnet/efcore#36558

[artiomchi]

This is amazing work @r-Larch! Thanks for doing this.

Regarding your comments:

1. I understand your concern about re-implementing the RelationalJsonHelpers. It doesn't seem perfect, but I don't currently know an alternative approach for this. I'm happy to go ahead with your current implementation until a new approach becomes viable.
2. That's an interesting one - I'd be somewhat tempted to allow support for this, but I'm worried about adding functionality that follows concepts that EF Core itself doesn't support. We could do this, but if EF implements it and changes their approach, we could end up with a clashing implementation.

Regarding that second point, we could either disable support for it for now, or alternatively enable it behind a feature env variable flag. It would be technically supported, but without guarantees that it will not change in future releases, depending on what the EF team does. If they implement it in the base library, we can remove the need for the flag

What would you think about this approach?

[r-Larch]

Hi @artiomchi ,

You are right, we should mirror the EF implementation and 'throw' in that case.

[r-Larch]

EF does not support complex table-shared properties with a child complex property mapped to JSON.
If we want to mirror the EF implementation, we could throw here if path is not null.

[artiomchi]

Going to take that suggestion on and apply it. I've moved the comment above into the if statement to make it more contextually accurate

[r-Larch]

It could be possible that this line-change fixes: #187 Does not handle type conversion/type adapters for pgsql
Requires tests to verify.