Changing mismatch tracking with DbContext and EF First code

When it comes to using EF Code First, there are two options for tracking changes:

  • Track changes based on snapshots
  • Track proxy based notification changes

Consider the following code at startup using each change tracking method. Suppose a DbContext instance has default configuration options.

var o = context.MySet.First(); o.MyProperty = 42; context.SaveChanges(); 

If an entity instance loaded and tracked by the context in the first line already has a value of 42 for "MyProperty", then its state in the change tracker is different during the call to "SaveChanges" in the third line.

  • Track changes based on snapshots - "No change" status.
  • Tracking changes based on notifications with Proxies - its status is โ€œModifiedโ€.

Given that when tracking changes based on notifications, an unnecessary update instruction will be sent to the database during a call to SaveChanges, I assume that most developers would prefer snapshot-based change tracking behavior.

Is this difference in behavior intentional?

Is there a way to achieve the same behavior as snapshot-based change tracking when using change tracking based on alerts with proxies?

Notice that I believe this is related to this proposal - http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/1015363-better-change-tracking-for-poco-proxies

+6
source share
1 answer

This behavior is intentional . The reason is that backward behavioral compatibility with old EntityObject based EntityObject that behave the same way - they count the property change to the same value as the real modification. The related article also shows that the new recommendation is to use snapshot change tracking and change tracking proxies only if you have performance issues when snapshot changes are tracked.

+6
source

Source: https://habr.com/ru/post/918411/


All Articles