EF Core change tracking

A DbContext is a unit of work. Every entity returned by a tracking query is remembered by its change tracker, in one of five states:

• Detached: not tracked at all.
• Unchanged: tracked, no differences from the database.
• Modified: tracked, some property differs; SaveChanges sends an UPDATE.
• Added: new; SaveChanges sends an INSERT.
• Deleted: removed; SaveChanges sends a DELETE.

var user = await db.Users.SingleAsync(u => u.Id == 1); // Unchanged
user.Email = "new@example.com";                       // still Unchanged until detected
await db.SaveChangesAsync();                           // UPDATE Users SET Email = ... WHERE Id = 1

Snapshots, not setters

Plain entity classes do not tell EF Core when a property is set. Instead, when an entity is tracked EF Core keeps a snapshot of its original values. DetectChanges, which SaveChanges calls for you, compares current values with the snapshot. Only properties that differ are marked modified, and only they appear in the UPDATE. A property set and then set back before detection is not a change at all. The model below keeps a snapshot dictionary per entity and compares, as DetectChanges does.

1public class Tracked2{3    public int Id;4    public Dictionary<string, string> Current = new();5    public Dictionary<string, string> Original = new();6}7 8public static class Solution9{10    static Tracked Load(int id, Dictionary<string, string> row) =>11        new() { Id = id, Current = new(row), Original = new(row) };   // snapshot on load12 13    static string DetectChanges(Tracked e)14    {15        var changed = e.Current.Keys.Where(k => e.Current[k] != e.Original[k]).OrderBy(k => k).ToList();16        return changed.Count == 0 ? $"user {e.Id}: no SQL" : $"user {e.Id}: UPDATE SET {string.Join(", ", changed)}";17    }18 19    public static List<string> Run()20    {21        var row = new Dictionary<string, string> { ["Name"] = "Ann", ["Email"] = "ann@a.io", ["City"] = "Oslo" };22        var one = Load(1, row);23        one.Current["Email"] = "ann@b.io";24 25        var two = Load(2, row);26        two.Current["City"] = "Rome";27        two.Current["City"] = "Oslo";              // set back before SaveChanges28 29        return new List<string> { DetectChanges(one), DetectChanges(two) };30    }31}

After a successful SaveChanges, added and modified entities become Unchanged with a fresh snapshot, and deleted ones become Detached. All the statements run in one transaction by default.

Identity resolution

Within one context there is at most one tracked instance per primary key. Query the same row twice and you get the same object back, and the values already in it win: a tracking query does not overwrite an entity you have modified with what the database now says. The model below reduces the context to an identity map keyed by primary key.

1public class User { public int Id; public string Email = ""; }2 3public class Context(Dictionary<int, string> database)4{5    readonly Dictionary<int, User> identityMap = new();6    public User Find(int id)7    {8        if (identityMap.TryGetValue(id, out var tracked)) return tracked;   // tracked wins9        var user = new User { Id = id, Email = database[id] };10        identityMap[id] = user;11        return user;12    }13}14 15public static class Solution16{17    public static List<string> Run()18    {19        var database = new Dictionary<int, string> { [1] = "ann@a.io" };20        var db = new Context(database);21 22        var first = db.Find(1);23        first.Email = "local@edit.io";                 // not saved yet24        database[1] = "someone-else@b.io";             // another request saves a change25 26        var second = db.Find(1);27        return new List<string>28        {29            "same instance: " + ReferenceEquals(first, second),30            "email: " + second.Email,31        };32    }33}

Choosing an API

• AsNoTracking() for read-only queries: no snapshots, less memory, faster materialisation.
• db.Users.Update(user) on a detached object marks every property modified, so the UPDATE writes every column, including ones another request changed in the meantime.
• Remove on an entity that is still Added simply detaches it; no SQL is sent.
• ExecuteUpdateAsync / ExecuteDeleteAsync (EF Core 7 and later) run one set-based statement directly and bypass the change tracker entirely, so tracked instances in the context are not updated.

Common mistakes

• Calling Update(entity) on an entity that is already tracked, "to be safe". It turns a one-column UPDATE into an every-column one.
• Keeping one DbContext alive for a long batch job. The tracker grows with every entity read, and DetectChanges gets slower each time.
• Expecting a second query to refresh a tracked entity. It returns the tracked instance; use Reload() or a new context.
• Tracking large read-only result sets. Use AsNoTracking().

What interviewers ask