aichallengesafrica
Take a challenge
HomeChallengesRepsProblemsLeaderboardTake a challenge

Tracking, and when not to

Somebody read that AsNoTracking is faster and put it everywhere, including on the method that saves. Decide per path: reads do not track, writes must, and the report that reaches the same row twice needs the identity map without the snapshots.

Intermediate20 min on the clock4 graded checks · 100 pointsPersistence with EF CorePro
Graded by reading your code against the checklist below.

What you build

  • The read path projects and does not track
  • The write path tracks, so SaveChanges can detect the change
  • The report keeps one instance per key without tracking
  • No AsNoTracking anywhere near a SaveChanges

Done means

Each path chooses tracking for a stated reason, and the update actually persists.

How it is graded

Published in full, before you start — every point is one of these and there is nothing else.

  1. The read path does not track+25Querying a database
  2. The write path is tracked+30Querying a database
  3. The report keeps one instance per key+25Querying a database
  4. No untracked query ends in a save+20Writing a row safely

What it teaches

Writing a row safelybeginner

Creating a record means deciding its id, checking it before it lands, and never modifying the list you were handed — because a half-written row is harder to find and fix than a rejected request.

The rest of Persistence with EF Core

The query that ran four hundred timesIntermediate · 20 minThe migration that lost a columnAdvanced · 20 minWhere the transaction endsAdvanced · 20 minThe concurrency tokenAdvanced · 20 min