I know this "feature" is documented, but I really think one the main reasons for using ORM has been smashed with EF:s Update functions way of working.
There is no actual change tracking at all since everything in the update gets marked modified even if nothing has actually changed. This also totally prevents using optimistic concurrency patterns.
Here is a small example, where client edits an order and changes the shipping address. Order has order rows, histories, included status and lot's of other related objects. Order rows includes stock products. This is how it should look like:
public void Update(Newtonsoft.Json.Linq.JObject input)
{
try
{
MyOrder order = Newtonsoft.Json.JsonConvert.DeserializeObject<MyOrder>(input.ToString());
db.Orders.Update(order);
db.SaveChanges();
}
catch (Exception ex)
{
// Do something
throw;
}
This however results in thousands (depending on the amount of the data on the order of course) of unnecessary SQL updates and stock change and other events firing on the application resulting even in more changes. Also if someone else was modifying something related at the same time, they will get an error since data has changed, though it actually hasn't. Same API is being used by third party clients too, so we can't rely on client side change tracking.
Yes, I know I can fix this myself by using Attach and writing code for doing the whole change tracking myself, but what is the point? Simple one liner suddenly became a horrible, monstrous code just in order to update an entity correctly which should be very basic functionality of the ORM.
Why does EF even have an Update function if it doesn't actually update, but just replace and marks everything modified?