Django Interview Questions — Medium

• 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().

---