.NET Framework and Core for Application Development
View All Tags
Yes. Each call to SaveChangesAsync runs in a transaction of its own, so if one row fails, none of them are saved. That's easy to prove with MySQL's own log, and it also shows you where the protection stops.
I used a TransactionScope once, and afterwards a plain query on the same pooled connection reported its isolation level as SERIALIZABLE. The scope's default level is Serializable, the driver sets it for the whole session, and nothing puts it back. Passing the level you want avoids all of it.
A request without my header got a 400 Bad Request with an empty explanation, and my endpoint never ran. The log had the reason: Required parameter "string source" was not provided from header. One ? decides whether a header is required.
I raised a value with ExecuteUpdateAsync, and read the product again, and got the old value back. The database had the new one. FirstAsync had gone to MySQL, read the new value, and then handed me the object it was already tracking, unchanged.
int.Parse on a number from configuration stopped the build with error CA1305: The behavior of 'int.Parse(string)' could vary based on the current user's locale settings. The analyzer has a point, and the fix is one argument, once you decide whose culture the text is in.
Asking for IsolationLevel.Snapshot failed with NotSupportedException: Snapshot isolation level is not supported. Coming from SQL Server, that sounds like MySQL can't do it. It can: MySQL's default level already reads from a snapshot, under a different name.
SELECT VERSION() is about the simplest query there is, and db.Database.SqlQuery<string>(...).FirstAsync() failed with Unknown column 's.Value' in 'field list'. My SQL has no s and no Value. EF Core added both, and it expects one thing from you.
GET /orders?status=99 didn't fail. My enum has three members, and the endpoint happily ran with status 99, which then filters to nothing, with no sign that the request was wrong. .NET's enum parsing allows this on purpose, so the check is yours to add.
?status=Placed worked, and ?status=placed gave a 400 Bad Request with no explanation. The reason was only in the log: Failed to bind parameter "Nullable<OrderStatus> status" from "placed". JSON bodies accept any case here, and query strings don't.
A request that listed the same product twice in one order got a 500, and the log had MySQL's Duplicate entry '2-9' for key 'order_lines.IX_order_lines_OrderId_ProductId'. The database was right to refuse. But a mistake in the request should be a 400, and it shouldn't take stock and open a transaction to find out.
