.NET Data Community Standup - New EF Core 7.0 APIs (Bulk Update)

EF Core 7.0 introduces the ExecuteUpdate and ExecuteDelete APIs, which allow you to easily use LINQ to express a database update or delete operation. These APIs can be far more efficient for applying changes to multiple rows based on a condition, e.g. “delete rows which have InActive set to true” (AKA bulk update scenarios). But in some scenarios, they also allow you to express changes over a single row in a much more succinct and simple way, simplifying your code. ExecuteUpdate and ExecuteDelete completely bypass EF’s change tracking and execute immediately, as opposed to when SaveChanges is called. Tune in to learn more and to explore the new possibilities that these new APIs bring!

[joseagustincarrenogallego]

I love how Chuck Norris has a lot of knowledge about EF! Thank you a lot

[FATPENGUIN]

[2:28] Start
[6:18] Community Links
[8:27] ExecuteUpdate and ExecuteDelete - **Shay**

[EricHarmon]

Shay, in regard to your statement "I do everything in async"..., I'd love to be able to say the same, but I have a major situation which prevents me from doing so, and that is that I have a number of places where I fetch data from a property setter (I'm using MVVM; not code-behind). For example, I may have a WPF app with a combo box and a grid. The combo box is loaded with a number of categories. Selecting a category loads the grid with items related to that category. I've ready numerous posts from other people, saying to never perform a database access from a property setter, because setters should be "instantaneous". I don't want to preload all items from the database and then simply filter them when the user selects a category from the category combo box, because I may have thousands of items in the database, and it would be wasteful in terms of memory usage, network bandwidth, and time. I was wondering if you might be able to weigh in on this, and offer your recommendation for being able to use *only* async EF calls, and yet still being able to handle this situation. By the way, I truly enjoy hearing you speak. Your pacing and delivery are great, and I always learn a lot from listening to you.

[eddieyanez]

What’s the name of ErikEJ’s library to use Microsoft.Data.SqlClient? It’s not named in the slide, nor linked in the description. Thanks!

[akyvi]

it helped me, I downloaded it, everything is fine

[suleymanov]

Is it only working with SqlServer, not working with PostgreSql for example.

[balborando]

Why so much code: ". ExecuteUpdateAsync(updates => updates.SetProperty(b => b.IsActive, false));"
Why not ExecuteUpdateAsync(b => b.IsActive = false);?

[jelle]

Is the whole async blob (NVARCHAR(MAX)) issue fixed for Microsoft SQL? Constantly I hear we should now use async, but entities or read operations containing a blob column of a few kilobytes will be orders of magnitude slower. Reads sync with 10MB gives 20ms, async 50 SECONDS!!! in a test we did with EF core 6.0.

[Suriprofz]

Why are there still no UpdateOrCreate methods ? And no bulkUpsrrts including graphs

[PticostaricaGS]

Why the sql is generated using a cast, it should not be required, the value could be converted directly before creating the sql, avoiding an unnecessary cast

[asakurahao]

why didn't have no auto migrations?

[younevilletube]

12:08. async only person but did miss 'AddRangeAsync'

[EgoPingvina]

Есть кто-нибудь, кто может вкратце на руском объяснить в чём суть?