EF Core safety
Understand the entity model, mappings, query shape, indexes, tracking needs, transaction boundary, concurrency behavior, and migration history before editing.
- Keep
DbContext scoped to a unit of work and never use one instance concurrently. Await each operation before starting the next.
- Project only needed data; avoid accidental N+1 queries, client evaluation assumptions, unbounded result sets, premature materialization, and unnecessary tracking (
AsNoTracking for read-only work when consistent with the repository).
- Propagate cancellation to async database calls. Use async methods for request-path I/O.
- Make transaction boundaries explicit when multiple writes must be atomic. Account for execution-strategy retries and external side effects; do not assume a database transaction covers remote calls.
- Handle optimistic concurrency deliberately when lost updates matter. Design retry/merge behavior rather than blindly overwriting.
- Treat migrations as production contracts: inspect generated operations, data loss, locks, defaults/backfills, deployment ordering, mixed-version compatibility, and rollback/roll-forward strategy.
Do not introduce a custom retry loop merely because a database failure might be transient. Add retry behavior only when explicitly requested or already required/configured by the architecture, prefer the provider's EF Core execution strategy, and verify idempotency, transaction boundaries, duplicate-write safety, timeout budget, bounded attempts, cancellation, and permanent-error classification.
Validate query behavior and SQL/performance when risk warrants it. Test provider-specific behavior with the appropriate provider; do not assume an in-memory provider reproduces relational semantics.
1---2name: ef-core-safety3description: Design, implement, or review Entity Framework Core queries, writes, migrations, and DbContext usage. Use only when a .NET task changes EF Core persistence behavior or investigates database performance/correctness.4---56# EF Core safety78Understand the entity model, mappings, query shape, indexes, tracking needs, transaction boundary, concurrency behavior, and migration history before editing.910- Keep `DbContext` scoped to a unit of work and never use one instance concurrently. Await each operation before starting the next.11- Project only needed data; avoid accidental N+1 queries, client evaluation assumptions, unbounded result sets, premature materialization, and unnecessary tracking (`AsNoTracking` for read-only work when consistent with the repository).12- Propagate cancellation to async database calls. Use async methods for request-path I/O.13- Make transaction boundaries explicit when multiple writes must be atomic. Account for execution-strategy retries and external side effects; do not assume a database transaction covers remote calls.14- Handle optimistic concurrency deliberately when lost updates matter. Design retry/merge behavior rather than blindly overwriting.15- Treat migrations as production contracts: inspect generated operations, data loss, locks, defaults/backfills, deployment ordering, mixed-version compatibility, and rollback/roll-forward strategy.1617Do not introduce a custom retry loop merely because a database failure might be transient. Add retry behavior only when explicitly requested or already required/configured by the architecture, prefer the provider's EF Core execution strategy, and verify idempotency, transaction boundaries, duplicate-write safety, timeout budget, bounded attempts, cancellation, and permanent-error classification.1819Validate query behavior and SQL/performance when risk warrants it. Test provider-specific behavior with the appropriate provider; do not assume an in-memory provider reproduces relational semantics.
dprakash2101