280 posts tagged with "C#"

To load several rows by their IDs, call Contains on the list inside your Where. It reads backwards the first time, and EF Core turns it into a plain SQL IN. An empty list is worth seeing too: it doesn't fail, and it doesn't return everything.

Most apps never need this, because one DbContext is enough. When you do have two, such as separate contexts for separate modules, they can share one transaction: they need the same connection, and the second has to be told about the transaction. Here it is, working and rolling back.

TransactionScope wraps code in a transaction without passing anything around: everything on the connection inside it joins in, and it commits only if you call Complete(). It works with EF Core and MySql.Data, with three things to get right. If you don't need its ambient behaviour, BeginTransactionAsync is simpler.

A DbContext remembers every entity it has loaded or been told about, until you say otherwise. ChangeTracker.Clear() makes it forget all of them, including changes you haven't saved. That's the fix for one nasty retry bug, and useful in a couple of other places.

Could not save changes. Please configure your entity type accordingly. tells you nothing, and it isn't meant to be read on its own. The real error is one level down, with a number you can test in code. Where it sits depends on which method threw, so a small helper is worth having.

LINQ covers most queries, and now and then you need SQL of your own: FOR UPDATE, SELECT VERSION(), or a query LINQ makes awkward. EF Core has three methods for that, and which one you use depends on what you want back.

When two people buy the last item, the safe way to decide who gets it is to let the database decide, in one statement. Put the stock check in the UPDATE's WHERE, and read how many rows changed. That's all of it, and every round I ran gave one winner and four polite refusals.

If another transaction holds a row, MySQL makes your statement wait up to 50 seconds by default. For a web request, that's far too long. Here's how to set a shorter limit from EF Core, on every connection, without relying on CommandTimeout, which doesn't do this job with MySql.Data.

Some settings belong to a connection, not a statement: a time limit, a session variable, a time zone. EF Core has a hook for exactly that. A DbConnectionInterceptor runs your SQL each time a connection opens, and it's inexpensive enough not to think about.

A savepoint lets part of a transaction fail while the rest carries on. In EF Core, you create one with CreateSavepointAsync, and EF Core also creates its own around each SaveChanges inside a transaction. If you've seen __EFSavePoint in MySQL's log, that's where it comes from.