C# Programming Language
View All Tags
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.
Under load, sales failed with MySqlException: Check constraint 'CK_products_QuantityOnHand' is violated. and an HTTP 500. The stock never went below zero, so the constraint had worked. The problem is that a buyer who should have heard "out of stock" heard "server error".
