I wasn't sure this would be worth 38 minutes of my life, but this is definitely worth it. Relational DBs solved a huge subset of problems, Doc DBs solved a different subset, and now you've taken a huge step towards merging both. This is important work you've done.
Wonderful new features, I have been using EF/EF Core for many years, but this video surprised me and my future work and projects shall benefit from this knowledge. Thanks you both.
Can you please give me a link to the video you mentioned @22:05? I'm very interested about the join aspect because we have some perf problems in our app with this topic
@ajcvickers I wonder how we can handle discriminator with json, example if address in UK may have different format that address in US and we use like interface (IAddress) or base abstract class , silly sample but I wonder if this can be achieve by the new EF core json support?
Excellent work,. all the time it was said that RDBMS do not have concept of arrays I was thinking ... Postges?? the end clarification that the native capabilities are used there was just the cherry on top of very impressive work. Well done guys, I just enjoy seeing you two on my screen. Congratulations on the cool set of examples and their order. I was thinkin that the sample with at least one visit will be better written with IS NOT NULL, with more than one will be where the Visits column value length is > than the length of textual form of a single date, etc. but those are hacks in comparison with your clear / canonical solution. Hacks may be faster but the understandable and always working code is better, even when generated. Thanks a lot. I may just start using EF now. It is good enough for me not writing all my SQL by hand. And that is something keeping in mind I am doing it since SQL server 4.2 Again, thanks a lot. Your work should be a pleasure to use.
We have similar code running on SQL Server in production without EF (using direct SQL) and performance on larger data sets (few hundred thousand records) is terrible. Stay away from this on SQL Server if you are at all concerned about performance. SQL Server at its core is very behind the curve on native array and document support. This should work great on PostgreSQL though!
@@Joooooooooooosh I mean at least it will actually work well on PostgreSQL. Maybe when SQL Server catches up to 2023 with native array and document support this will be a thing, but until then, this is a total waste of time of the EF team.
Automatically converting a .NET primitive array to a JSON formatted array as a parameter for a query is pretty nice. Now I won't have to do this manually.
Why are you guys not using CTEs or top instead of first for consistency when working with JSON (I'm presuming you are borrowing from Observables)? Also where are you storing the metadata to know what the composition of the JSON columns are within the database?
Cool stuff. The section about collections of simple datatypes being mapped as JSON, does that apply to the Postgresql variant as well or does it natively support the Postgresql implementation of arrays (which I believe would be more efficient)? Maybe it is a question for the NPGSQL guys...
Cool, but just mentioning "perf" so briefly kind of falsely gives the impression that this JSON support is usable in anything but extremely small databases. It isn't. The JSON_VALUE thing can be indexed, but the collections not so much. PostgreSQL kind of handles it. The contains optimization is great, but something that has been solved by other OR mappers years ago. Still, good to see.
I wasn't sure this would be worth 38 minutes of my life, but this is definitely worth it. Relational DBs solved a huge subset of problems, Doc DBs solved a different subset, and now you've taken a huge step towards merging both. This is important work you've done.
I love the new inline primitive array support that works without any config!
Well done! Solving real world problems and doing it in an elegant yet powerful way!
Wonderful new features, I have been using EF/EF Core for many years, but this video surprised me and my future work and projects shall benefit from this knowledge. Thanks you both.
17:20 , this is really good, currently have to use predicates for that, glad it's been added to EF8.
Wow! Stunning! So glad I didn't miss this video.
The best ORM in any language just keeps getting better ❤
i love these guys! wish this were longer, lol
Unfortunately anything with JSON arrays can't be effectively indexed. Most of these queries will perform terribly on any large tables.
Hey guys - before we had table params we used that hack of using xml to pass in lists, - its not a new technique...
Definitely one of my favorite talks.
This is amazing thank you..
Can you please give me a link to the video you mentioned @22:05? I'm very interested about the join aspect because we have some perf problems in our app with this topic
Fantastic job!
You guys are rockstars!!
Brilliant presentation.
@ajcvickers I wonder how we can handle discriminator with json, example if address in UK may have different format that address in US and we use like interface (IAddress) or base abstract class , silly sample but I wonder if this can be achieve by the new EF core json support?
Excellent work,. all the time it was said that RDBMS do not have concept of arrays I was thinking ... Postges?? the end clarification that the native capabilities are used there was just the cherry on top of very impressive work. Well done guys, I just enjoy seeing you two on my screen.
Congratulations on the cool set of examples and their order. I was thinkin that the sample with at least one visit will be better written with IS NOT NULL, with more than one will be where the Visits column value length is > than the length of textual form of a single date, etc. but those are hacks in comparison with your clear / canonical solution. Hacks may be faster but the understandable and always working code is better, even when generated. Thanks a lot. I may just start using EF now. It is good enough for me not writing all my SQL by hand. And that is something keeping in mind I am doing it since SQL server 4.2
Again, thanks a lot. Your work should be a pleasure to use.
this is awesome, great work thank you !
We have similar code running on SQL Server in production without EF (using direct SQL) and performance on larger data sets (few hundred thousand records) is terrible. Stay away from this on SQL Server if you are at all concerned about performance. SQL Server at its core is very behind the curve on native array and document support. This should work great on PostgreSQL though!
Yeah, it is cool to write the query but performance is always an issue when the volume comes.
Exactly. So much work was put into a feature that is pretty much an antipattern in the real world.
@@Joooooooooooosh I mean at least it will actually work well on PostgreSQL. Maybe when SQL Server catches up to 2023 with native array and document support this will be a thing, but until then, this is a total waste of time of the EF team.
Automatically converting a .NET primitive array to a JSON formatted array as a parameter for a query is pretty nice. Now I won't have to do this manually.
I love these guys so much, Microsoft's best speakers! Thanks for this love EF core!
Brilliant
Excellent, I'm going to update the version
Why are you guys not using CTEs or top instead of first for consistency when working with JSON (I'm presuming you are borrowing from Observables)? Also where are you storing the metadata to know what the composition of the JSON columns are within the database?
How to handle it when 'Address' has another object? Does anyone have any ideas for configuration?
Cool stuff. The section about collections of simple datatypes being mapped as JSON, does that apply to the Postgresql variant as well or does it natively support the Postgresql implementation of arrays (which I believe would be more efficient)? Maybe it is a question for the NPGSQL guys...
Sry, It got answered later on by Shay
What version of SQL Server first supported keywords such as OPENJSON? This is my first time hearing about it.
will this work exact same way for postgre sql
What's the datatype for the column holding the json array?
Thank you for this video. Great features. Could you provide the code of your presentation, please?
is JSON parsing faster then query planning?
This is not just SQL Server? Oracle has no support yet...
Cool, but just mentioning "perf" so briefly kind of falsely gives the impression that this JSON support is usable in anything but extremely small databases. It isn't. The JSON_VALUE thing can be indexed, but the collections not so much. PostgreSQL kind of handles it.
The contains optimization is great, but something that has been solved by other OR mappers years ago. Still, good to see.
But you don't support Cosmos Db hierarchical partition keys. You always seem to be way behind the curve when it comes to Cosmos Db.
What could go wrong
Talk about flying too close to the sun... jeez, just bring a plague down on us all, why don't you?!
what a useless video....