Django Interview Questions

• Looping over books and touching book.author fires one query per book (N+1).
• select_related - SQL JOIN for FK/OneToOne: single query, Book.objects.select_related("author").
• prefetch_related - second query + in-Python join for M2M/reverse FK: Books.prefetch_related("tags").
• Deep paths supported (select_related("author__profile")), Prefetch objects allow filtered prefetches. Detection: django-debug-toolbar, nplusone, or assertNumQueries in tests. Always name the detection tool - interviews love that.

---

• Chaining builds an abstract description; execution triggers on iteration, list(), bool(), len(), slicing with step, or pickle.
• Consequences:
  • Building then never iterating = zero cost.
  • if queryset: executes - surprising DB hit in conditionals; use .exists().
  • Caching: results memoize on the SAME QuerySet after first evaluation; reusing a half-consumed iterator can surprise - re-chain from manager for fresh intent.

---

from django.db.models import F, Q
Book.objects.update(views=F("views") + 1)          # atomic in SQL
Book.objects.filter(Q(year=2024) | Q(isbn__isnull=True))

• F references column values server-side - race-free increments without read-modify-write round trips.
• Q composes OR/NOT logic beyond implicit AND of kwargs; combinable with &/| and parentheses. Advanced note: F also enables comparisons between fields and optimistic concurrency via conditional update returning rowcount.

---

from django.db import transaction
with transaction.atomic():
    book = Book.objects.select_for_update().get(pk=pk)
    book.stock -= 1; book.save()

• atomic() wraps a block/decorator in BEGIN…COMMIT/ROLLBACK; nested atomics become savepoints.
• select_for_update() locks rows until commit - pair INSIDE atomic, else no-op.
• transaction.on_commit(fn) defers side effects (emails, cache busts) until data is durable - classic interview favorite. Autocommit default means EVERY statement commits alone unless wrapped - say it explicitly.

---

• Built-ins: pre_save/post_save, pre_delete/post_delete, m2m_changed, request_started...
• Risks: invisible control flow (saving a model somewhere triggers email far away), hard to test/order, fire during loaddata/migrations unexpectedly. Alternatives preferred: override save()/delete() explicitly, service layer functions, or transaction.on_commit hooks for reactions. If signals stay: keep them thin (enqueue task only), document loudly, register receivers in AppConfig.ready().

---

• QuerySet builds a tree of compiler nodes (WhereNode/expressions), deferred until get_compiler().as_sql() runs against the vendor backend.
• Leaks interviewers expect: DISTINCT + order_by on joined models forces sorting columns into SELECT breaking distinctness (fix via .order_by() reset or subqueries); aggregates over joins multiply rows; extra() escapes the model entirely.
• Vendor variance: window functions, ON CONFLICT, index hints vary by backend - portability claim has edges. Depth signal: mention sqlcompiler alias generation and how annotate aliases collide.

---

• Readers see snapshot; writers create row versions - long transactions hold vacuum behind.
• ORM hazards: iterating huge querysets inside atomic() extends transaction lifetime → table bloat; fix via iterator chunks OUTSIDE atomic or keyed batch loops each committing.
• Hot updates churn index entries (HOT updates need no index-touching columns changed) - updating indexed status column frequently defeats HOT; design indexes accordingly.
• Serialization failures under REPEATABLE READ/SERIALIZABLE require retry wrappers around atomic blocks.

---

Skeleton:

def transfer(src, dst, amount, idem_key):
    if Transfer.objects.filter(idem_key=idem_key).exists(): return existing
    try:
        with transaction.atomic():
            t = Transfer.objects.create(..., status="pending", idem_key=idem_key)
            accounts locked via select_for_update; balances adjusted
            transaction.on_commit(lambda: queue.enqueue("settle", t.id))
    except IntegrityError: return existing  # concurrent duplicate

Points: unique idem_key arbitrates concurrency; on_commit guarantees enqueue only post-commit (avoid ghost jobs); worker itself idempotent re-checking state before applying external effects.

---

• select_related: single SQL with LEFT JOINs per relation path; alias explosion on very deep chains; nullable handled automatically.
• prefetch_related: executes IN-query per relation binding ids in Python; chunking via queryset.iterator not applicable - memory proportional to fetched set.
• Nested Prefetch objects compose filtered child sets; cannot reference sibling prefetch results within same round-trip (second-level prefetches run sequentially). Edge worth naming: reverse one-to-one uses select_related path efficiently; reverse FK always prefetch family.

---

• Enable RLS policies on tenant tables (USING (tenant_id = current_setting('app.tenant')::uuid)).
• Middleware SETs SET LOCAL app.tenant inside atomic block per request (connection-scoped, pooling caveats with pgbouncer transaction mode → use SET SESSION on dedicated connections).
• Django layer: manager enforces tenant filter too (defense in depth), migrations disable RLS for superuser-owned migration role. Pitfalls: connection reuse leaking settings; bulk updates crossing tenants silently failing under policy.

---