Native JSON support for EFCore

[weitzhandler]

Related: https://github.com/aspnet/EntityFrameworkCore/issues/4021 https://github.com/aspnet/EntityFrameworkCore/issues/2282

In my vision, there should be an attribute let's say SqlJsonAttribute or whatever, that when we use it on an entity property, a string-based (e.g. nvarchar) column is created for it in the DB, and a HasConversion is added to the DbContext for that property instructing EF to transform its contents into JSON (whether it's a complex object, array or whatever), using the JSON serializer registered with the IDbContextServices/IDatabaseProviderServices fail-safing to JSON.NET.

A middleware will be injected to the EF runtime that intercepts the queries and rewrites all the parts that concern those jsonized properties into OPENJSON SQL queries, so that from the point of view of the layer using EF, no special attention has to paid when querying those properties as far as it concerns LINQ to SQL support.

[tuespetre]

I like it a lot.

OPENJSON has been on my radar since writing this test case: https://github.com/tuespetre/Impatient/blob/b1c10f55f34c60cdd477b0ffcca5bbf0395e4f2a/test/Impatient.Tests/QueryTests.cs#L4276-L4301

I imagine implementing that will lay most of the needed foundation for other kinds of JSON usage.

[weitzhandler]

I've updated my question, please have a look! Thank you for this awesome work!

[tuespetre]

I've got a proof-of-concept in the branch json-party. Here's a test case using OPENJSON, JSON_VALUE, and JSON_QUERY:

https://github.com/tuespetre/Impatient/blob/0cc45a85b8ebc27d94643f19db7a8c834177ee66/test/Impatient.Tests/QueryTests.cs#L4617-L4643

While not ridiculously dynamic in the sense of using IDictionary<string, object> or anything like that, at least the complex sub-properties could be iterated upon rapidly without necessitating migrations or schema changes. I'm going to need to let it stew for a while and think about possible gotchas; at first thought, the trickiest areas are going to be:

• guaranteeing that the originating projection can always be traced back from a given JSON function expression in order to preserve special expressions, for instance, EntityMaterializationExpressions which need to interact with change tracking
• making appropriate decisions in regards to the JsonSerializerSettings and whatnot to use on a column-by-column basis. Some columns may need to be camelCase, some snake_case, some need to use a specific ContractResolver, etc. and while having support at all is a good start, those options will be important to consider down the line.

[tuespetre]

I've gone ahead and merged what I have so far into master. Short of offering a means of providing a custom JsonSerializerSettings I don't know that there's much else to do besides handle issues as they come up.

Now we only handle the query side of things, not anything else in EF (for now) so it looks like maybe EF Core 2.1 with its ValueConverters will be the ticket for this to actually get some use.

[weitzhandler]

Thanks for your awesome work!

[tuespetre]

Oops! Looks like I forgot that with JSON, array indexing can be a translatable thing.

https://aspnetcore.slack.com/archives/C0E1PN874/p1525166978000116

Right now it should be working although it will run on the client side. I’m reopening this until I can get some tests and implementation for translating that to server side in there.

[tuespetre]

I’ve got something working for both array indexing (with constant and variable index arguments) as well as other indexing expressions. I’m still trying to decide whether or not to limit the ‘other’ indexing expressions to string keys on dictionary types, and I’m still trying use a little bit of combinatorics to come up with a suitable test suite for the functionality.