Entity Framework Core 8: Improved JSON, queryable collections , and more… | .NET Conf 2023

[Music] um okay we're live okay sorry about that it's a little bit confusing back here okay so this is actually the talk with three titles uh so there's the title that you just heard that we submitted and then uh a couple of weeks ago a few weeks ago now we did an internal talk that covered a lot of the same stuff and we thought had a really nice narrative so we decided to do that uh for this talk and I gave it this title at the for the internal talk document relational convergence and EF core 8 which to be honest even though I wrote it is a bit pretentious and I don't really know what it means so really with the new EFA fun with Jason so that's all you need to know okay but um we are going to talk about uh document versus relational databases um document databases are good at some things and relational databases are good at some things uh EF core comes into the picture by leveraging commonality between between these two so we want to enable common patterns so for example regardless of your database you can write a link query pull back some data make a change to that call Save changes and save the unit of work back to your database um but we also want to leverage the specific power of each database system so where a document datab is good at point reading an entire document we want to make EF core function in that way and make it possible for you to effectively read the entire document when you're using a document database and in fact go going further this we want the way EF Works to promote the best practices for the database system you're on so that rais us an interesting question Arthur which we get a lot does that mean that we can um treat EF as a sort of abstraction over your database in the sense that we can swap out for example I'm using SQL server and I can swap it out to use something like Cosmos and my code will just run as it is can that work so that's a very good question Shai and the short answer is no uh and the reason is because we want to Leverage The power of the different systems and behave differently depending on the backend database but enough slides let's go and actually look at some code um so code yeah so I've got a very simple model here it's a customer entity type it's got some details and the details have lists of address and phone numbers um and then I've got uh an AF core DB context here so this DB context basically is the way EF core connects everything up and tells us how to use how to map to the database what the model is and everything like that uh in particular we're saying use relational database in this case I'm running a local SQL server and we're telling it to map this customer object to the database now we're not telling it explicitly how to map the rest of these things the nested things in here we're going to let it do the appropriate thing for uh whatever database it's using so initially a relational database and I have just a little application that's going to cleanly recreate my database it's going to insert three sample customers and call Save changes so uh let's run it hopefully works first time running Live code and you can see that EF has created four tables for this for this mapping so let's let's go look at that Shai what's going on here right so anybody who's familiar with relational databases will find this very you know this is just a classical thing what if does here it Maps your code model in net to four tables in your uh relational SQL database very classical you've got a table for the customer uh for the C customers for the customer details the addresses and the phones the thing to understand here is that a single customer the single like the data for a single customer is sprayed across four tables that's the relational way to think about it all the addresses for the customer go to one table all the phone numbers go to another table you've got uh you know the main stuff in the customer table and they're all linked together via what's called foreign key relationships right there's foreign keys and primary keys and all that classical stuff right so nothing to write home here this is the way EF has worked uh since forever and that's how most orms do their job job right so let's go back to the code now uh and let's actually change this context and we're not the only thing we're going to change here is we're going to say actually use a document database instead of a relational database and for this we're using uh Azure Cosmos DB um and so I'm going to run the same code but just against the document database now and actually when this runs you should see that the output is quite different to what it had before uh Visual Studio is uh messing up the output there let me close it and again okay here we go so before remember it created the schema it created those four tables document databases don't have a schema so there's no tables to create um so you don't see any output for EF doing that it did create a cosmos database first using the background using the emulator and it inserted uh three uh customers into there so let's go look at what that looks like in the database show so very very different obviously instead of getting four tables with the data spread across what we're seeing here is a single customer represented as a Json document so typically document databases you can think of them as representing the data in Json even if it's not always exactly what goes on and behind the scenes but the main point here is that document databases represent hierarchical uh structures of data so you have your customer uh things and you can see the addresses and the phone numbers and everything inside one single document The crucial Point here is that the related stuff again the addresses and and the phone numbers are collocated their inside they're contained within that one document rather than uh connected to it via foreign keys or or all kind of you know things like that and of course uh we also have the other documents for the other customers so instead of having rows across four different tables that represent the customer we have one document for One customer another document for another customer and a final document for the Third customer and I think that illustrates for anybody who's unfamiliar with document databases this is a great comparison to kind of understand that it's very different strategy for modeling your data and we're going to see how that's going to affect things now right okay so let's go back to the code uh and what what I'm actually going to do now remember we said document databases are good at certain things and one of those things was Point read of an entire document so I've I'm using my document database here and in my application I'm going to go and say okay well let's bring back a document so I've got this query that's going to say bring back one of those documents with the name Baxter uh and then we'll just going to drill down into Baxter just to show that we've got everything back so we're going to print out the number of addresses that Baxter has um so when I run this um hopefully we should see uh fairly reasonable output so we're running uh We've executed a a query against the document database to bring back that one customer and indeed he has two addresses because uh we brought back the whole document there um so that's that's what we kind of expect from using a document database that's ef's behavior for that um but what happens now if I do that thing that Shai said and that we get asked what happens if I take my really simple application all it's doing is bring back back to right and outputting the addresses what happens if I switch out that and put a relational provider behind it so I'm going to do that uh by opening the context here again and changing this to use SQL Server again instead of use Cosmos so we're going to go back to creating the four tables that we saw before so when I run this what we get at the bottom is a n refer exception Shai why are we getting an old ref exception here right it's a demo why are we getting an exception right so we actually plan for this exception this is not a failure in our demo the thing is when you use a relational uh provider and you instruct EF to get the customers what EF will do is not get the entire customer graph including all the addresses and the phone numbers because those are actually over there in different tables with all the foreign key relationships and everything right so what EF will do is only bring back the the the data from the customer table itself and then if you uh take that customer and attempt to drill down into the addresses they're not populated because if hasn't hasn't loaded it for you so you get reference exception but sh I can fix that right so you know if I sure we don't want to bring back all of the data because it's you know not best practice to do that but if I can if anybody's used EF they know about include right include just says okay bring back the details and the addresses and the phone numbers with this query so if I run that we shouldn't get a n ref exception anymore that's right and indeed we don't so it's all good exactly because you've now explicitly instructed EF to load the entire graph or specifically the addresses in the phone numbers and so on and so forth however it's worth examining the SQL always a good idea to examine the SQL by the way uh even though you're using link to express your queries so if you look at the SQL you'll see that we have three joins in there uh which correspond to those three tables right uh because as we as we are we've repeatedly said data is spread across different tables and loading the entire customer implies doing uh bringing in data from other tables now joins are actually quite um you know quite um a big thing for a database to do it implies a lot of work the database has to go to the other table find the exact row that corresponds based on the foreign key relationship and all that kind of stuff so that is exactly why if doesn't do it for you by default when targeting a relational database right and you have to say that you're interested in those addresses if EF were to bring back the entire graph all the time then performance would be absolutely awful because that's not how relational databases are meant to be used and I think that really illustrates once again that point that we made before each database has its strengths and weaknesses and you definitely cannot just take a relational databases database and use it like a document database or vice versa sometimes people porting applications between the two database types attempt to do this kind of thing they think they can swap they can't it doesn't work like it doesn't but but shy and this is where that word convergence comes in from that one of the titles to this talk um because prti yeah that pretentious worth so basically the competitive environment that exists now between document databases and relational dat all know SQL databases but document datas and relational databases is what we're focusing on and it's pushing document databases to be to do better at things that relational databases are traditionally good at you know the transactionality that kind of thing um and likewise um the fact that document databases are so good at dealing with documents and doing this kind of scenario is pushing relational databases to have support for document capabilities in that and so what we're actually going to do is change the mapping in EF core now in the relational database so let's go back to the code so I'm going starting to go into the cool territory yeah so I'm going back to my context here where I'm using SQL server and I'm saying oh actually okay map that differently we don't want four tables for our scenario that we're doing here we still want a relational database because there's lots of other data here but for this particular customer and the customer's information we we actually want to be able to bring that back very quickly as a point read so I can tell EF okay well when you get C when you see customer bring back details addresses and phone numbers automatically and oh by the way map this to Jason in the relational database so this is is actually going to put it in a Json col in a relational column it's going to create a document there um before I run this code I'm just going to change two other things so I'm going to remove the primary keys from these nested types because they're not actually needed when you map into a document they weren't needed by the way for the cosmos one either I just didn't remove it for the sake of time there um but these things are embedded inside the document right there's no foreign keys in Keys now so there's no need for Keys there's no need for keys there exactly sh um and and uh the one last thing I'm going to do is go back here and I'm going to remove these includes because we've told EF bring it back always right um so now hopefully if I've done all the things we should we run this again we'll see completely different thing happening the first thing we see is we're not creating four tables anymore we're creating one table so sh what's happening here right so no more four tables right which I think will mean no more joints but that single table that we now see has this column at the right edge of it called details and what is inside that details thing for each customer is a Json document containing all that data that we map to it so what we're effectively doing here is establishing some sort of hybrid model this is a relational database this SQL server but we're now embedding a Json document so kind of a document database sort of way to model data inside a column in that relational database and that allows us to mix and match right like uh some a while ago people used to say you know it's either relational or document or no SQL versus SQL so that is not the way things work definitely not anymore right you don't have to choose one or the other you can actually that's the convergence part you can use a relational database with some uh you know uh document features and also vice versa which is what you're seeing here and crucially this also gives us as Arthur said um you know the way to work if so if my data is good for modeling in this way and I want to just get it back in one single you know thing without joints then this is the perf way to do that and it doesn't mean that I can't have other relationships in a more traditional relational way right so mix and match exactly so speaking of that this is the query you can see we're not doing any joins this is a very efficient query that's going to bring back all the details from the backer and his addresses and of course it doesn't n ref because we've got everything right um so that's very cool um one of the things that makes this possible there there's really two things that make this this kind of thing possible in eore and that's what we're going to dig down to the first is that eore has a rich model and so it knows what's uh Behind these things so it knows what's in that document and the second thing is that relational databases and this isn't just SQL Server all major relational databases have first class support for manipulating and looking into and doing things with Json documents uh and so as we'll see this isn't just a serialization of stuff into an opaque column right this is a lot more than that um and we we'll we'll start looking at that by actually running some a little bit more interesting queries on this so I'm going to replace this here with a query so sh what's going on here in this query so just a normal link query right for EF but there's actually something very interesting Happening Here recall that the SE details that you see in that uh wear operator actually maps to a Json column in the database right this is not a normal column and the region property that you saw um you know dotted inside there actually refers to a Json property inside that that document so if we switch back to the query what we're actually asking EF here to do is to filter our customers based on something that's a Json property inside a column right that means that the Json has to be able to parse to actually understand that Json inside there in order to do this efficiently right this couldn't be done like you can't do this if you just kind of dump uh Json into your column that doesn't mean you can search based on the contents inside because the database has to understand that kind of stuff so let's run this link query and see what happens okay it's going to get more and more exciting yes very cool so EF here is leveraging a SQL Server function uh called Json value this is exactly the kind of thing where arthor said that uh relational databases are getting Json support this is it this is the kind of thing Json value is a simple function you give it uh a Json document here that's the details column containing our Json document we saw that just before and you give it also a p inside that Json document to a property to a simple property and it will extract so it basically parses that Json document gets that region extracts it and then we can compare that to Europe effectively asking the database get me all customers uh where the uh uh region is Europe basically very simple just works okay excellent so I think um that one um oh we yeah so that one worked in ef7 because this uh this journey were on uh implementing J support is kind of a multi multi-year thing and we're we're a relatively small team so that was something that worked in F7 but in af8 we've really ramped up what's available and this is a query that was that didn't work in ef7 but now does work in E8 sh right I'm I'm very excited about this this specific feature that we're delivering so we're again looking at C details which is a document but instead of looking at a at a scaler property inside the region from before we're now looking at addresses which is an array so that's ajacent array and because it's a collection we can now compose a link operator any on top of that thing and effectively ask uh uh ask the database for all customers where there's at least one address in the UK right uh once again we're composing link operators on a Json array that's inside a document that's in a column that's starting to get a little bit complicated here but I hope everybody's kind of right but very very cool let's see what it generates because it's uh I think it's easier sometimes to understand some of these things when you see the SQL possibly sometimes it's even more complicated though so here we have another another Json primitive of SQL Server uh called openjson now openjson uh a bit like Json uh value that we saw before you give it a Json document that's the details and you give it a path just like before but the path in this case is a path towards to an array of Json things not a scaler and that array contains various objects with properties the addresses and what we're saying here EF knows the structure so once again we have a rich model we know what's inside that Json array so we instruct SQL Server to parse out that Json array as a relational table this is a sort of a transformation from Json into a table uh what is effectively a temporary table we're telling SQL Server what the actual schema in there is so we're saying each one of those elements in the Json array has a city a country a postc the street and so on and so forth and these become the columns in the new relational array that gets transformed out of this array and once we have that table it's just a table in a normal relational world and we can put it after a from like in SQL and then we can use where to filter on the country where it's only in the UK and so on and so forth so we've transformed ajacent array inside Nest inside some document into a table and then use that to filter on the customers that we want to extract very cool okay so we're going to we're going to take uh a step into the unnown now because this is a query that we just threw together literally like 10 minutes ago before this session which is also a no no on a big conference right you know throw it together and hope it works but this is so sh you talk to it and then we'll run it and see whether it actually works so we have not even tested this but I'm confident that this is going to work so what you're seeing here um is something that goes in the same direction right uh uh we are going into the details thing but at this point point we look at the addresses and we compose an any operator on top of those addresses and we also project out things from outside of those addresses right so we're composing operators uh both in the wear uh clause and also in the projection in the select operator right uh we're going to fetch all customers where there's at least one address in the UK and then we're going to project out the first one that has that that is in the UK right so let's give this a try we'll give it a try but before we run it this is actually you know even if this doesn't work this is something that quote does work in ef8 now uh which didn't work in F7 again and that's projection of parts of uh a collection inside a Json document because that's another thing that's like really kind of important for um this being able to work with adjacent document inside a relation as or in fact inside a document database you need to be able to sometimes just select part of it and bring it back because you don't want everything um and so this is going to try and do that hopefully um it's a fairly complex query if it works so uh there we go it work it does actually work right okay you want to talk about this this this is definitely the case where it's not easier when you see the sequel now now uh people have to be like uh a bit more expert in SQL in order to understand it but the crucial part here is the where exists that you see below is the same thing we saw before so we can actually disregard that that's the same thing that we saw for this filters out customers that have an address in the UK but in order to get out to project the part that we want we use an outer apply that's also called a lateral join and other databases like postgress which means for every customer that gets uh filtered here that that gets selected we're going to kind of join we're going to do a correlated join that's an outer apply and we're going to join against the open Json so against that table that's constructed out of that array so I'm not going to spend too much time on this but I'm just going to say we once again take out those addresses in table form and then join that with the customer so that we can project it out so this is quite a lot of uh you know deep Machinery uh going on behind the scenes to to produce this query but the lovely thing here is that you don't have to care as users of EF you just use Link to express what you want and we just do the heavy lifting for you so also I should say that that perf is obviously a complex area and there are perf issues and perf things and you know all of these things play into it so you know we're showing you some things I'll talk actually last year if you want to go look at it we'll talk a little bit about the per aspects of some of these things and where makes sense to do joins or not joins but we know perf is a complex thing so you know bear bear with us um on uh not going too much detail of the perf stuff in this talk um okay we're going to switch to something a bit different now um so this looks like some of the other queries we've done but it's actually different and it's different because of this property right so we kind of glossed over this before but what we have on customer here is something that was not possible before with e f we have a primitive of a a collection of a primitive type so daytime is what we call A Primitive type it's like an inter string it's not a complex entity type with a lot of properties inside it's just a primitive value and we just have a list of those now this is something that uh uh people uh have been struggling with for I want to say decades with relational databases just the simple thing of sticking a bunch of ins on your you know on your table is actually not very easy because relational databases just don't have the concept of an array or or collection so what you do is you either stick them with commas like comma the liit Del limited like numbers inside a string maybe you stick them in a separate table and do uh one to many relationship but that's complicated and you have a joint so performance problems so it really is a very simple thing but not very easy to do so with eore a this is really one of the most exciting things that we're bringing for EF core8 you can just do a list of Primitives like list of daytime you see here or int or string and EF core will implicitly map that to ajon array in the database so this happens automatically you don't have to actually configure it in any way if you look at the database schema then you see that we have this visits column and you can see inside this is a string column in SQL Server uh or an N varar Max to be precise and it contains a representation of that list right inside you can see representations of day times inside Json so this is a way to finally uh resolve that problem but it doesn't just allow you to serialize those things which is which you could already do before with commas it also allows you to query them because e knows what's going on uh we're going to run a query yeah exactly so we're going to ask for all the customers who have at least one visit that once again requires the database to go and parse what's going on inside that array let's go see okay so let's run that so friend open Jason again our open that's the star of this show for sure it's not you and me it's open Json what open Json here is doing it's it's very similar to uh to what we had before we're giving it visits the difference from before is before we used it on something inside the Json document and we also used it on a an array of complex things addresses with many many fields here what we're doing is using it on a primitive collection which means that there's only one column in the table that comes out the type of that column is daytime two which you see that EF specifies yeah in in to open Json and then we just select the count of that and and select those rows where it's bigger than one so once again parsing inside that primitive collection and querying it and I want to I want to point out um when we look at this next query something that you point you you've mentioned a couple times already this is not just a opaque list of numbers in the database or list of strings in the database right right it because EF has this Rich model where it knows actually these are date times and because SQL Server can then use that with the open Json we can do things that are very specific to the semantics of this list being actually date times and not something else people have been people have been storing you know uh uh numbers with com commas or dates with commas in like for for a long long time but then you can't do anything with it if you just stick it in the database there's no way to ask your database to filter on something inside right unless you do it via string Searchers or something anyway so so here we are we also have parameters right which is important right uh so this query goes even further so we have the same primitive collection visits which is a uh a collection of dates Day times and we're composing a link operator on top of that any but what we're doing here goes a step further what we want to do is get all the customers where the there's at least one visit within a certain range of years right so we're going to extract the year out of each one of those Day times in that primitive collection and we're going to check whether it's within that range so this already goes far beyond you know what we did before it's worth mentioning before we switch over to the SQL that the actual from and to here are parameters they're not literals inside the query the 2010 and 2019 the from and two they're outside the query and that means that EF will translate them into parameters that's going to be very important for our our next and last uh code sample so bear that in mind okay so let's run this one first okay here we go open Jason again open Json again uh uh we will see that we will see it one once more so we do open Json on the visits we instruct SQL Server to parse that out as a table of day times with one column containing a lot of day times right but then because we know it's a daytime and you've instructed us to extract the year we're going to use the SQL Server function date part to extract a year out of a daytime right uh once again we can do that because we know we keep repeating this but that's the cool thing so we're excited about it we know what's what's what's actually stored inside the database so we can do that what what you just saw and the from in the two that you saw before those things that we I just mentioned as parameters you can see that they're not actually in the sequel you can see those uh uh you know placeholders there the from undor 0 and the from uh and the 2core 0 they're sent out of band they're not inside the SQL that's important again to our for our next um demonstration okay so really we're really going to switch up gears now um so this is a this we're going to show a case where there's actually no Json in the databases at all but Json is integral to this and this is actually fixing an issue that um when we started on ef8 this was the second most voted issue on our repo um and so it's really cool that we're able to bring all of this together and fix something that has been a big problem for EF users and it's not really anything to do with document databases or Jason y um I run on seven first yeah but let me uh just say a few words just so that we can understand the query itself and then absolutely we want to see what what happened on seven so this query is actually a very classical kind of query we're going to ask for all customers whose member sense um uh column here is one of a list so is contained within a list so special days is a parameter uh remember from the last query so it's a parameter but it's a list parameter containing various dates and we want uh all customers whose member s is one of those things so this is a very very uh uh classical kind of thing you have a bunch of IDs and and you want all the rows that correspond to that have those IDs right everybody you know knows this everybody has done this um you use the contains operator to do it and it's remarkably complicated to do this in a relational database once again because of the lack of proper support for arrays so now let's run this in EF course 7 and let's run this what we did before Oh yes we're doing in seven okay I did run it in seven so we we did work you're doing great everything is cool yeah so what you see here our our contains operator in link We translated it uh uh predictably to in so it's a very uh trivial uh translation right where member since in we open parenthesis and then the Curious Thing is that those values which you saw in the parameter list uh Back Inn net are now actually uh present as literals or constants inside the SQL so remember a few minutes ago I said that EF generally uh wants to put parameters out of band um and not inside the SQL and this is not happening here because there's no concept of an of a param array once again because relational databases just don't have the concept of an array now why is this a problem and this is where it gets interesting so it turns out when you send a SQL query to the to the database the database has to do a lot of heavy lifting in order to execute it it needs to par the SQL it needs to plan for how it's going to actually uh uh you know perform that query that's actually a lot of complicated work so in order to make things go fast the database has a caching mechanism so every time it sees the same SQL it knows oh I've already seen the equal I've already planned for it so I can use the cache plan from the last time that I I I did this right so as long as you properly parameterize your queries and the SQL itself doesn't change you're good everything is going to perform well however what you see here means that every time you run this query with different values in that parameterized list in.net you're going to get different I'm glossing over this is actually a very complicated thing and and uh performance-wise it goes Way Beyond what I just said it's actually more complicated but I will say this is a big performance problem and as arthor said this was our second most highly voted issue up until this release so it's also one of the most discussed issues so if you're interested that thread has a lot of analysis both from people at Microsoft people uh in the community who contributed to it um looking at all the potential performance things so let's see what we came up with um for uh EFA on this shy so I'm going to switch back to the ef8 and run the same query this is going to tie the whole talk together you'll see yes all right surprised that we see open Json again probably not we've been harping on this so what happens here as Arthur said before there's no Json in the database we're not querying a Json column like we did in the previous things what we are now doing is uh using open Json over a parameter this is what you see in the parenthesis here the special days so if core took your array that was in net and basically serialized it into a string with ajon array representation it packed the uh you know the net array into adjacent array and then it sent that to SQL Server as a string parameter on the SQL server side we place this thing into an open Json which unpacks it back from Json form into a table so this is a way of sending um pretty much a table or or or more more specifically A Primitive collection from uh the client to the database which is something that's been notoriously difficult uh uh in general with relational databases again very complicated subject we're not going into all the nuances once that thing is unpacked uh as dates we can once again use it in the normal way and translate contains to in so we've worked around the issue and now this SQL that's the crucial thing here is not going to vary if you change the actual dates in the list what's going to change is only that string parameter containing the Json array rather than the SQL which is what happened in eore 7 right so now you have one SQL no matter what happens with the squarey perf win very good excellent okay that's that's really impressive stuff so that that's actually making use of the first class Json support in the database the EF Rich model together to solve a problem that doesn't actually involve any Json in the database or any document databases so that's that's that's very cool um okay let me go back to my slides here and got quick summary um so we've talked a lot about uh document and relational databases the fact that they both have strengths but the competitive environment is pushing them both to be better at each other's areas uh EF comes into this because um we're expanding on what we've done in previous versions to allow you to use patterns against both of those and those can be common patterns um but they can also be patterns that are very specific to the type of database that you're using uh and in particular what we've dug into in this in this talk is how we're using the first class support uh for Jason in the database and by the way we showed SQL server but this uh Works in EFA with SQL Li and with postgres which will be released in a couple of days um and you can use the rich EF model together with that to do some very powerful query patterns sh right uh I mean it's it's hard to uh to uh cover everything this is a complicated set of features there's a whole lot of functionality being delivered for efcore a this theme of primitive collections we really did a huge effort on um it uh as Arthur said this also works in other types of databases um if you use this by the way on posterus for example A Primitive collection does not actually map to adjacent array because posterus is the one database that does have a concept of array like a native array in the database so the same idea of a primitive collection in EF core is actually going to map to a normal uh uh like a more a non-json array so it's not even stored as a Json string in the database but rather as an array type and all of the query the rich querying capabilities map to uh array querying in posters with some very specific things which is I think a testament to how the EF approach kind of works uh we're very very we try very hard to be database agnostic and not code specifically for a specific database but rather you know uh uh build it with other databases at mine and and so on and so forth uh there's the collections of entities inside Json is is like new support that's happened uh we also leverage again this primitive collection concept to work well with parameters so you saw how we took a parameter which was an array and composed contains on it which with this cool uh uh translation you can actually compose any chain of Link operators on top of a parameter that's an array and that is incredibly powerful you can even do that on what's called an inline collection so you can do new like a new array you open the curlies you put a thing there and then you start composing join and Union and any link operator it's all going to get translated which is all very new and cool good stuff good stuff okay so um we talked about some some specific things um but there's also a lot of other new stuff in EFA I'm not going to go through this list uh aka.ms whats new that's uh updated today it's got detailed documentation on all the major things in ef8 plus runnable samples that you can download from GitHub GitHub to run um so that's EFA oh one more thing so um we've talked about document databases um a few months ago now we were approached from uh the people at mongodb uh about creating an EF core provider so we have been working uh over the last few months with Damen guard and the folks from mongodb to create uh a mongod DP provider for efcore uh there's a link there aka.ms EFC H mongodb that goes to a blog post that has links to the announcement and then new get packag and all of that kind of stuff um as you might expect it works very like the relational um the sorry the cosmos provider and I've got just a very quick uh demo of that here for you um so what we've done it looks exactly like you would expect for Cosmos or SQL Server except we've got use mongod DB and then everything else is the same uh so I'm just going to change to run that one uh and then when we run this what we've actually got is um I've got Docker running in the background it might not be warmed up um with a test container of mongod DB and we're going to use EF core to insert three documents into that uh here we go and then we're going to use Mongo's lowlevel apis to extract the bson out of it and convert that into Json that we can see and here is that Json it's it's hard to see in the console but uh I have a handy slide of course uh and you can see it looks very much like what you'd see in the uh Cosmos database except it's got specific stuff and there's three documents because it's all collocated like it should be okay so we're almost out of time so we' got some questions in a minute but thank you for for watching this everybody um we've been showing the work of the net data access team which is me and Shai uh but then also Andre Bryce and macei and then we've got our contributors as well um and there's three more EF core talks from the community ATF comp I've got the titles on there so go check them out uh and then there's a bunch of links but really the one the only one you need is aka.ms ef8 that will take you to the blog post announcing it with the links to everything else uh the codes on my GitHub if you want to look at it for today um and we do shy and I do a live stream uh to to YouTube and twitch every two weeks we've we've got one coming up in about two weeks time where we'll do a tour of ef8 features so hopefully you can join us for that uh and we're done

Channel: dotnet

Views: 29,510

Keywords: .NET

Id: _8iH5QnkIJo

Length: 38min 56sec (2336 seconds)

Published: Wed Nov 15 2023