← Python

Django (ORM, views, templates, admin, signals)

← Django (ORM, views, templates, admin, signals)

Select a question from the sidebar

20 questions in this topic

Question 1 / 20

What is the standard Django project structure and what does each file do?

When you run django-admin startproject myproject and python manage.py startapp myapp, Django creates a specific directory structure:

Project-level files:

manage.py: Command-line utility for running management commands
myproject/settings.py: Configuration (database, installed apps, middleware, etc.)
myproject/urls.py: Root URL configuration
myproject/wsgi.py: WSGI entry point for production servers
myproject/asgi.py: ASGI entry point for async servers

App-level files:

myapp/models.py: Database models (ORM)
myapp/views.py: View functions or classes
myapp/urls.py: App-specific URL patterns (you create this)
myapp/admin.py: Admin site registration
myapp/apps.py: App configuration
myapp/tests.py: Tests
myapp/migrations/: Database migration files

Django follows the apps pattern -- each feature is a self-contained app with its own models, views, and URLs.

Pseudo Code

myproject/
  manage.py              <- CLI entry point
  myproject/
    __init__.py
    settings.py          <- all configuration
    urls.py              <- root URL routing
    wsgi.py              <- production WSGI
  myapp/
    __init__.py
    models.py            <- database models
    views.py             <- request handlers
    urls.py              <- app URL patterns
    admin.py             <- admin registration
    migrations/          <- schema migrations
    templates/myapp/     <- app templates
    static/myapp/        <- app static files

Code

# myproject/settings.py (key settings)
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'myapp',  # your app
]

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

# myproject/urls.py (root URL config)
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('myapp.urls')),
]

# myapp/models.py
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)
    body = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

# myapp/views.py
from django.http import JsonResponse
from .models import Article

def article_list(request):
    articles = Article.objects.all().values('id', 'title', 'created_at')
    return JsonResponse({'articles': list(articles)})

# myapp/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('articles/', views.article_list, name='article-list'),
]

# myapp/admin.py
from django.contrib import admin
from .models import Article

@admin.register(Article)
class ArticleAdmin(admin.ModelAdmin):
    list_display = ('title', 'created_at')
    search_fields = ('title',)

Key Points

•Django uses apps pattern -- each feature is a self-contained app
•settings.py holds all configuration; apps must be in INSTALLED_APPS
•Root urls.py includes app-level urls.py via include()
•manage.py is the CLI; wsgi.py/asgi.py for production deployment

Gotchas

•Forgetting to add your app to INSTALLED_APPS means models and templates are not found
•App names must be unique across the project
•templates should be in app/templates/appname/ to avoid naming collisions
•migrations/ directory must have __init__.py or Django ignores it

Django projects contain apps. Key files: settings.py (config), urls.py (routing), models.py (ORM), views.py (handlers), admin.py (admin site). Apps must be in INSTALLED_APPS.

•Apps are self-contained modules with models, views, urls
•Add apps to INSTALLED_APPS for Django to discover them

# settings.py
INSTALLED_APPS = ['myapp']

# urls.py
from django.urls import path, include
urlpatterns = [path('api/', include('myapp.urls'))]

# myapp/models.py
class Post(models.Model):
    title = models.CharField(max_length=200)

Forgetting INSTALLED_APPS means models and migrations are invisible

Question 2 / 20

How does the Django ORM work for defining models and making queries?

Django's ORM maps Python classes to database tables. Each model class inherits django.db.models.Model, and class attributes define columns.

Field types:

CharField, TextField, IntegerField, FloatField, BooleanField
DateTimeField, DateField, TimeField
ForeignKey, ManyToManyField, OneToOneField
EmailField, URLField, SlugField, UUIDField, JSONField

QuerySet API (lazy evaluation):

QuerySets are lazy -- they don't hit the database until evaluated (iteration, slicing, list(), len(), bool()).

Key query methods:

all(), filter(), exclude(), get()
order_by(), distinct(), values(), values_list()
count(), exists(), first(), last()
create(), update(), delete(), bulk_create()
select_related(), prefetch_related() (eager loading)
annotate(), aggregate() (computed fields)

Pseudo Code

# Define
class User(models.Model):
    name = models.CharField(max_length=100)
    email = models.EmailField(unique=True)

# Query (lazy)
qs = User.objects.filter(name='Alice')  # no DB hit yet
for user in qs:  # DB hit happens here
    print(user.name)

Code

from django.db import models
from django.utils import timezone

# Model definition
class Author(models.Model):
    name = models.CharField(max_length=100)
    email = models.EmailField(unique=True)
    bio = models.TextField(blank=True, default='')
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        ordering = ['name']

    def __str__(self):
        return self.name

class Article(models.Model):
    title = models.CharField(max_length=200)
    slug = models.SlugField(unique=True)
    body = models.TextField()
    author = models.ForeignKey(Author, on_delete=models.CASCADE,
                               related_name='articles')
    tags = models.ManyToManyField('Tag', blank=True)
    published = models.BooleanField(default=False)
    views = models.PositiveIntegerField(default=0)
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        ordering = ['-created_at']

    def __str__(self):
        return self.title

class Tag(models.Model):
    name = models.CharField(max_length=50, unique=True)

    def __str__(self):
        return self.name

# CRUD Operations
# Create
author = Author.objects.create(name='Alice', email='alice@example.com')
article = Article.objects.create(
    title='Django ORM Guide',
    slug='django-orm-guide',
    body='Full guide...',
    author=author,
    published=True
)

# Read
all_articles = Article.objects.all()  # lazy QuerySet
published = Article.objects.filter(published=True)
unpublished = Article.objects.exclude(published=True)
single = Article.objects.get(slug='django-orm-guide')  # raises if 0 or 2+
first = Article.objects.filter(author=author).first()  # None if empty

# Field lookups
recent = Article.objects.filter(created_at__gte=timezone.now())
titled = Article.objects.filter(title__icontains='django')
by_authors = Article.objects.filter(author__name__in=['Alice', 'Bob'])

# Update
Article.objects.filter(slug='django-orm-guide').update(views=100)
article.views = 200
article.save()  # saves all fields (or use update_fields=['views'])

# Delete
Article.objects.filter(published=False).delete()

# Aggregation
from django.db.models import Count, Avg, Sum, Max

stats = Article.objects.aggregate(
    total=Count('id'),
    avg_views=Avg('views'),
    total_views=Sum('views')
)

# Annotation (per-row computed fields)
authors_with_counts = Author.objects.annotate(
    article_count=Count('articles')
).filter(article_count__gt=5)

# Eager loading (N+1 prevention)
articles = Article.objects.select_related('author').all()  # FK join
articles = Article.objects.prefetch_related('tags').all()  # M2M prefetch

# Values (dict output)
Article.objects.values('title', 'author__name')[:5]

# Chaining
results = (Article.objects
    .filter(published=True)
    .exclude(views=0)
    .select_related('author')
    .order_by('-views')
    .values('title', 'views')[:10])

Key Points

•Models map Python classes to database tables; fields define columns
•QuerySets are lazy -- chained filters build SQL without executing until evaluated
•Field lookups use double underscores: field__gte, field__icontains, fk__field
•select_related (FK joins) and prefetch_related (M2M) prevent N+1 queries

Gotchas

•get() raises DoesNotExist if no match and MultipleObjectsReturned if multiple matches
•save() writes ALL fields by default -- use update_fields for partial updates
•auto_now=True means the field cannot be set manually -- it always updates on save
•QuerySets are lazy but accessing .count() or iterating triggers a DB query

Django ORM: model classes map to tables, fields to columns. QuerySets are lazy and chainable. Key: filter(), exclude(), get(), create(), update(), select_related(). Use __ for lookups.

•Lazy QuerySets, double-underscore lookups
•select_related/prefetch_related prevent N+1

class Post(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(User, on_delete=models.CASCADE)

# Query
posts = Post.objects.filter(author__name='Alice', title__icontains='django')
posts = posts.select_related('author').order_by('-id')[:10]

get() raises exceptions if not exactly one result

Question 3 / 20

What are Q objects and F expressions in Django?

Q objects

Q objects allow complex queries with OR, AND, NOT logic. Without Q, filter() only supports AND.

F expressions

F objects reference model field values in queries, allowing database-level operations without loading data into Python. Used for:

Comparing fields to each other
Atomic updates (increment without race conditions)
Annotations and aggregations

Pseudo Code

Q objects:
  Q(status='active') | Q(status='pending')  # OR
  Q(status='active') & Q(role='admin')       # AND
  ~Q(status='deleted')                       # NOT

F expressions:
  F('views') + 1           # increment field in DB
  F('price') * F('quantity')  # field arithmetic

Code

from django.db.models import Q, F, Value
from django.db.models.functions import Concat, Upper

# Q objects: complex lookups
# OR: articles that are published OR have 100+ views
Article.objects.filter(
    Q(published=True) | Q(views__gte=100)
)

# AND + OR combined
Article.objects.filter(
    Q(author__name='Alice') & (Q(published=True) | Q(views__gte=50))
)

# NOT: exclude deleted articles
Article.objects.filter(~Q(status='deleted'))

# Complex search
def search_articles(query):
    return Article.objects.filter(
        Q(title__icontains=query) |
        Q(body__icontains=query) |
        Q(author__name__icontains=query)
    ).distinct()

# F expressions: reference field values
# Atomic increment (no race condition)
Article.objects.filter(id=1).update(views=F('views') + 1)

# Compare two fields
popular = Article.objects.filter(views__gt=F('author__articles__count'))

# Field arithmetic
from django.db.models import ExpressionWrapper, DecimalField

Order.objects.annotate(
    total=ExpressionWrapper(
        F('price') * F('quantity'),
        output_field=DecimalField()
    )
)

# Update based on another field
Article.objects.update(title=Upper(F('title')))

# Combine F with timedelta
from datetime import timedelta

Article.objects.filter(
    updated_at__gt=F('created_at') + timedelta(days=7)
)

# Annotate with F
Article.objects.annotate(
    full_title=Concat(F('author__name'), Value(': '), F('title'))
)

# Conditional expressions with Q
from django.db.models import Case, When, IntegerField

Article.objects.annotate(
    priority=Case(
        When(published=True, views__gte=100, then=1),
        When(published=True, then=2),
        default=3,
        output_field=IntegerField()
    )
).order_by('priority')

Key Points

•Q objects enable OR, NOT, and complex boolean logic in queries
•F expressions reference field values for database-level operations
•F('field') + 1 does atomic updates without loading into Python
•Combine Q and F for powerful database-level computations

Gotchas

•Q objects must come before keyword arguments in filter(): filter(Q(...), keyword=val)
•F expressions operate at the database level -- Python operators may not behave identically
•F('field') + 1 in update() is atomic; obj.field += 1; obj.save() is NOT atomic
•Complex F expressions may need ExpressionWrapper with explicit output_field

Q objects: OR/NOT logic in queries (Q(a=1) | Q(b=2)). F expressions: reference field values for DB-level operations (F('views') + 1 for atomic increment).

•Q for OR/NOT, F for field references
•F updates are atomic (no race conditions)

from django.db.models import Q, F

# OR query
Article.objects.filter(Q(published=True) | Q(views__gte=100))

# Atomic increment
Article.objects.filter(id=1).update(views=F('views') + 1)

Q objects must precede keyword args in filter()

Question 4 / 20

How do Django migrations work?

Django migrations track changes to your models and apply them to the database schema incrementally.

Commands:

python manage.py makemigrations -- detect model changes, create migration files
python manage.py migrate -- apply pending migrations to the database
python manage.py showmigrations -- list all migrations and their status
python manage.py sqlmigrate app_name 0001 -- show SQL for a migration
python manage.py migrate app_name 0001 -- migrate to a specific version
python manage.py migrate app_name zero -- unapply all migrations for an app

Migration files:

Stored in app/migrations/ as Python files. Each contains a list of operations (CreateModel, AddField, AlterField, etc.) and dependencies on other migrations.

Data migrations:

Use RunPython to migrate data (not just schema).

Pseudo Code

1. Change models.py
2. python manage.py makemigrations  -> generates migration file
3. python manage.py migrate          -> applies to database

Migration file structure:
  dependencies = [('app', '0001_initial')]
  operations = [
      migrations.AddField('model', 'field', models.CharField(...))
  ]

Code

# After changing models:
# python manage.py makemigrations myapp
# python manage.py migrate

# Example migration file (auto-generated)
from django.db import migrations, models

class Migration(migrations.Migration):
    dependencies = [
        ('myapp', '0001_initial'),
    ]

    operations = [
        migrations.AddField(
            model_name='article',
            name='slug',
            field=models.SlugField(default='', unique=True),
            preserve_default=False,
        ),
    ]

# Data migration (manually created)
# python manage.py makemigrations myapp --empty -n populate_slugs

from django.db import migrations
from django.utils.text import slugify

def generate_slugs(apps, schema_editor):
    Article = apps.get_model('myapp', 'Article')
    for article in Article.objects.all():
        article.slug = slugify(article.title)
        article.save(update_fields=['slug'])

def reverse_slugs(apps, schema_editor):
    pass  # nothing to reverse

class Migration(migrations.Migration):
    dependencies = [
        ('myapp', '0002_article_slug'),
    ]

    operations = [
        migrations.RunPython(generate_slugs, reverse_slugs),
    ]

# Squashing migrations (combine many into one)
# python manage.py squashmigrations myapp 0001 0010

# Check for migration issues
# python manage.py makemigrations --check  # exits 1 if changes detected

Key Points

•makemigrations detects model changes; migrate applies them
•Migration files are version-controlled Python files with operations and dependencies
•Data migrations use RunPython for non-schema changes
•squashmigrations combines many migration files into one

Gotchas

•Always run makemigrations after changing models -- don't manually edit migrations
•Renaming a model field generates RemoveField + AddField (data loss!) -- use RenameField manually
•Migration conflicts occur when two branches modify the same app -- use --merge to resolve
•Never delete migration files that have been applied to production databases

makemigrations detects model changes and creates migration files. migrate applies them. Data migrations use RunPython. Never delete applied migration files.

•makemigrations creates, migrate applies
•RunPython for data migrations

# Terminal:
# python manage.py makemigrations
# python manage.py migrate
# python manage.py showmigrations
# python manage.py sqlmigrate myapp 0001  # see SQL

Field renames generate delete+add by default -- use RenameField

Question 5 / 20

What are function-based views (FBVs) vs class-based views (CBVs) in Django?

Django supports two styles of views:

Function-Based Views (FBVs)

Simple functions that take a request and return a response
Explicit, easy to understand
Use decorators for common functionality
Better for one-off or unique views

Class-Based Views (CBVs)

Classes that inherit from Django's view classes
Built-in generic views for common patterns (ListView, CreateView, etc.)
Use mixins for reusable behavior
Better for CRUD operations and standard patterns

Generic CBVs:

ListView, DetailView -- display
CreateView, UpdateView, DeleteView -- CRUD
TemplateView, RedirectView -- utility
FormView -- form handling

Pseudo Code

FBV:
  def my_view(request):
      return HttpResponse('Hello')

CBV:
  class MyView(View):
      def get(self, request):
          return HttpResponse('Hello')

Generic CBV:
  class ArticleList(ListView):
      model = Article
      # automatically renders article_list.html

Code

from django.http import HttpResponse, JsonResponse
from django.shortcuts import render, get_object_or_404, redirect
from django.views import View
from django.views.generic import ListView, DetailView, CreateView, UpdateView, DeleteView
from django.contrib.auth.decorators import login_required
from django.contrib.auth.mixins import LoginRequiredMixin
from django.urls import reverse_lazy

# Function-Based View
def article_list(request):
    articles = Article.objects.filter(published=True)
    return render(request, 'articles/list.html', {'articles': articles})

@login_required
def article_create(request):
    if request.method == 'POST':
        form = ArticleForm(request.POST)
        if form.is_valid():
            article = form.save(commit=False)
            article.author = request.user
            article.save()
            return redirect('article-detail', pk=article.pk)
    else:
        form = ArticleForm()
    return render(request, 'articles/form.html', {'form': form})

# Class-Based View (basic)
class ArticleListView(View):
    def get(self, request):
        articles = Article.objects.filter(published=True)
        return render(request, 'articles/list.html', {'articles': articles})

    def post(self, request):
        # handle POST
        pass

# Generic CBVs (much less code)
class ArticleListView(ListView):
    model = Article
    template_name = 'articles/list.html'  # default: article_list.html
    context_object_name = 'articles'       # default: object_list
    paginate_by = 10

    def get_queryset(self):
        return Article.objects.filter(published=True)

class ArticleDetailView(DetailView):
    model = Article
    template_name = 'articles/detail.html'

class ArticleCreateView(LoginRequiredMixin, CreateView):
    model = Article
    fields = ['title', 'body', 'published']
    success_url = reverse_lazy('article-list')

    def form_valid(self, form):
        form.instance.author = self.request.user
        return super().form_valid(form)

class ArticleUpdateView(LoginRequiredMixin, UpdateView):
    model = Article
    fields = ['title', 'body', 'published']
    success_url = reverse_lazy('article-list')

class ArticleDeleteView(LoginRequiredMixin, DeleteView):
    model = Article
    success_url = reverse_lazy('article-list')

# URL configuration
from django.urls import path

urlpatterns = [
    # FBV
    path('articles/', article_list, name='article-list'),
    # CBV (must call .as_view())
    path('articles/', ArticleListView.as_view(), name='article-list'),
    path('articles/<int:pk>/', ArticleDetailView.as_view(), name='article-detail'),
    path('articles/new/', ArticleCreateView.as_view(), name='article-create'),
    path('articles/<int:pk>/edit/', ArticleUpdateView.as_view(), name='article-update'),
    path('articles/<int:pk>/delete/', ArticleDeleteView.as_view(), name='article-delete'),
]

Key Points

•FBVs are simple functions; CBVs are classes with method-per-HTTP-verb
•Generic CBVs (ListView, CreateView, etc.) handle common patterns with minimal code
•CBVs use .as_view() in URL config; FBVs are referenced directly
•LoginRequiredMixin for CBVs; @login_required for FBVs

Gotchas

•CBVs must use .as_view() in urls.py -- forgetting it causes TypeError
•Generic CBV defaults (template names, context names) can be confusing -- override explicitly
•CBV method resolution order matters when using multiple mixins
•FBVs are often clearer for complex one-off logic; CBVs shine for standard CRUD

FBVs: simple functions, explicit. CBVs: classes with generic views (ListView, CreateView) for less code. FBVs for unique logic, CBVs for standard CRUD.

•FBVs for unique logic, CBVs for standard CRUD
•CBVs use .as_view() in URL config

# FBV
def article_list(request):
    return render(request, 'list.html', {'articles': Article.objects.all()})

# CBV
class ArticleList(ListView):
    model = Article
    paginate_by = 10

# urls.py
path('articles/', ArticleList.as_view(), name='list')

Forgetting .as_view() causes TypeError

Question 6 / 20

How does Django URL routing work?

Django URL routing maps URL patterns to view functions/classes using path() and re_path() in urls.py.

Key functions:

path(route, view, kwargs=None, name=None) -- simple pattern matching
re_path(regex, view, kwargs=None, name=None) -- regex-based patterns
include(module) -- includes another urls.py file

Path converters:

<int:pk> -- integer
<str:slug> -- string (no slashes)
<slug:slug> -- slug (letters, numbers, hyphens, underscores)
<uuid:id> -- UUID
<path:rest> -- string with slashes

URL namespacing:

app_name in app's urls.py for namespace
reverse('app:view-name') to build URLs

Pseudo Code

# Root urls.py
urlpatterns = [
    path('admin/', admin.site.urls),
    path('blog/', include('blog.urls', namespace='blog')),
]

# blog/urls.py
app_name = 'blog'
urlpatterns = [
    path('', views.index, name='index'),           # /blog/
    path('<int:pk>/', views.detail, name='detail'), # /blog/42/
]

Code

from django.urls import path, re_path, include, reverse
from django.http import HttpResponse

# Views
def index(request):
    return HttpResponse('Home')

def article_detail(request, pk):
    return HttpResponse(f'Article {pk}')

def user_profile(request, username):
    return HttpResponse(f'Profile: {username}')

def date_archive(request, year, month):
    return HttpResponse(f'Archive: {year}/{month}')

# URL patterns
urlpatterns = [
    # Basic path
    path('', index, name='home'),

    # Path converters
    path('articles/<int:pk>/', article_detail, name='article-detail'),
    path('users/<str:username>/', user_profile, name='user-profile'),

    # Multiple converters
    path('archive/<int:year>/<int:month>/', date_archive, name='archive'),

    # Include app URLs
    path('blog/', include('blog.urls')),
    path('api/v1/', include('api.urls', namespace='api-v1')),
    path('api/v2/', include('api.urls', namespace='api-v2')),

    # Regex patterns (for complex matching)
    re_path(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),
]

# App-level urls.py with namespace
# blog/urls.py
app_name = 'blog'
urlpatterns = [
    path('', views.blog_index, name='index'),
    path('<slug:slug>/', views.blog_detail, name='detail'),
]

# URL reversing
from django.urls import reverse

# In Python code
url = reverse('article-detail', kwargs={'pk': 42})  # '/articles/42/'
url = reverse('blog:detail', kwargs={'slug': 'my-post'})  # '/blog/my-post/'

# In templates
# <a href="{% url 'article-detail' pk=article.pk %}">{{ article.title }}</a>
# <a href="{% url 'blog:detail' slug=article.slug %}">Read more</a>

# Custom path converter
class FourDigitYearConverter:
    regex = '[0-9]{4}'

    def to_python(self, value):
        return int(value)

    def to_url(self, value):
        return f'{value:04d}'

from django.urls import register_converter
register_converter(FourDigitYearConverter, 'yyyy')

urlpatterns = [
    path('archive/<yyyy:year>/', views.year_archive),
]

Key Points

•path() for simple patterns with typed converters; re_path() for regex
•include() delegates URL handling to app-level urls.py
•Name all URLs for reverse() and {% url %} template tag
•app_name + namespace for URL namespacing across apps

Gotchas

•URL patterns are tried in order -- first match wins
•Trailing slashes: Django's APPEND_SLASH setting redirects /path to /path/ by default
•reverse() raises NoReverseMatch if the URL name doesn't exist or args are wrong
•Namespace requires app_name in the included urls.py

path('route/<int:pk>/', view, name='name') maps URLs to views. include() delegates to app urls. reverse('name', kwargs={}) builds URLs. Name all patterns.

•path() with converters, include() for app delegation
•Name all URLs for reverse() and templates

from django.urls import path, include

urlpatterns = [
    path('articles/<int:pk>/', views.detail, name='article-detail'),
    path('blog/', include('blog.urls')),
]

# reverse('article-detail', kwargs={'pk': 1}) -> '/articles/1/'

First match wins -- order matters

Question 7 / 20

How does the Django template system work?

Django Template Language (DTL) provides template inheritance, tags, and filters similar to Jinja2 but with some differences.

Key syntax:

{{ variable }} -- output a variable
{% tag %} -- template tags (logic)
{# comment #} -- comments
{{ variable|filter }} -- apply filter

Template inheritance:

{% extends 'base.html' %} -- inherit from parent
{% block name %}...{% endblock %} -- define overridable sections

Key differences from Jinja2:

No function calls with arguments in expressions: {{ obj.method }} not {{ obj.method() }}
No inline if/else expressions
{% for %}...{% empty %}...{% endfor %} for empty loops

Pseudo Code

base.html:
  {% block content %}{% endblock %}

child.html:
  {% extends 'base.html' %}
  {% block content %}
    {% for item in items %}
      {{ item.name|title }}
    {% empty %}
      No items found.
    {% endfor %}
  {% endblock %}

Code

# views.py
from django.shortcuts import render

def article_list(request):
    articles = Article.objects.filter(published=True)
    return render(request, 'articles/list.html', {
        'articles': articles,
        'total': articles.count(),
    })

# templates/base.html
BASE_TEMPLATE = '''
<!DOCTYPE html>
<html>
<head>
    <title>{% block title %}My Site{% endblock %}</title>
    {% block extra_css %}{% endblock %}
</head>
<body>
    <nav>
        <a href="{% url 'home' %}">Home</a>
        {% if user.is_authenticated %}
            <span>{{ user.username }}</span>
            <a href="{% url 'logout' %}">Logout</a>
        {% else %}
            <a href="{% url 'login' %}">Login</a>
        {% endif %}
    </nav>

    {% if messages %}
        {% for message in messages %}
            <div class="alert alert-{{ message.tags }}">
                {{ message }}
            </div>
        {% endfor %}
    {% endif %}

    <main>
        {% block content %}{% endblock %}
    </main>

    {% block extra_js %}{% endblock %}
</body>
</html>
'''

# templates/articles/list.html
LIST_TEMPLATE = '''
{% extends "base.html" %}
{% load static %}

{% block title %}Articles ({{ total }}){% endblock %}

{% block content %}
<h1>Articles</h1>

{% for article in articles %}
    <article>
        <h2>
            <a href="{% url 'article-detail' pk=article.pk %}">
                {{ article.title|truncatewords:10 }}
            </a>
        </h2>
        <p>By {{ article.author.name }} on {{ article.created_at|date:"F j, Y" }}</p>
        <p>{{ article.body|truncatewords:30 }}</p>
        {% if article.tags.exists %}
            Tags: {% for tag in article.tags.all %}
                <span>{{ tag.name }}</span>{% if not forloop.last %}, {% endif %}
            {% endfor %}
        {% endif %}
    </article>
{% empty %}
    <p>No articles published yet.</p>
{% endfor %}

{% if is_paginated %}
    <nav>
        {% if page_obj.has_previous %}
            <a href="?page={{ page_obj.previous_page_number }}">Previous</a>
        {% endif %}
        <span>Page {{ page_obj.number }} of {{ page_obj.paginator.num_pages }}</span>
        {% if page_obj.has_next %}
            <a href="?page={{ page_obj.next_page_number }}">Next</a>
        {% endif %}
    </nav>
{% endif %}
{% endblock %}
'''

# Common filters
FILTER_EXAMPLES = '''
{{ name|lower }}              {# lowercase #}
{{ name|upper }}              {# uppercase #}
{{ text|truncatewords:20 }}   {# first 20 words #}
{{ price|floatformat:2 }}     {# 2 decimal places #}
{{ date|date:"Y-m-d" }}       {# date formatting #}
{{ html|safe }}               {# mark as safe (no escaping) #}
{{ count|pluralize }}         {# "s" if count != 1 #}
{{ list|join:", " }}          {# join list items #}
{{ value|default:"N/A" }}     {# default if None/empty #}
{{ text|linebreaks }}         {# \n to <p> and <br> #}
{{ text|slugify }}            {# "My Title" -> "my-title" #}
'''

Key Points

•Template inheritance with extends/block; {% empty %} for empty for-loops
•{% url 'name' %} for URL generation; {% load static %} for static files
•Filters: truncatewords, date, floatformat, default, safe, pluralize
•Auto-escaping is on by default -- use |safe only for trusted content

Gotchas

•Cannot call functions with arguments in templates: {{ obj.method }} calls with no args
•{% load %} must be in every template that uses custom tags (not inherited)
•forloop.counter starts at 1, forloop.counter0 starts at 0
•|safe disables auto-escaping -- XSS risk if used with user input

DTL: {{ var }} for output, {% tag %} for logic. Template inheritance via extends/block. {% url 'name' %} for URLs. Auto-escaping on by default.

•extends/block for inheritance, {% empty %} for empty loops
•Auto-escaping prevents XSS

{% extends 'base.html' %}
{% block content %}
  {% for item in items %}
    {{ item.name|truncatewords:5 }}
  {% empty %}
    No items.
  {% endfor %}
{% endblock %}

Cannot call functions with arguments in templates

Question 8 / 20

How do you customize the Django admin site?

Django's admin site provides an auto-generated CRUD interface for your models. Customize it via ModelAdmin classes.

Key customizations:

list_display: Columns shown in list view
list_filter: Sidebar filters
search_fields: Searchable fields
list_editable: Inline editing in list view
readonly_fields: Non-editable fields
fieldsets: Group fields in edit form
inlines: Edit related models on the same page
actions: Bulk actions on selected items

Pseudo Code

@admin.register(Article)
class ArticleAdmin(admin.ModelAdmin):
    list_display = ('title', 'author', 'published', 'views')
    list_filter = ('published', 'created_at')
    search_fields = ('title', 'body')
    list_editable = ('published',)

Code

from django.contrib import admin
from .models import Article, Author, Tag

# Inline editing of related models
class ArticleInline(admin.TabularInline):  # or StackedInline
    model = Article
    extra = 1  # empty forms to show
    fields = ('title', 'published')

@admin.register(Author)
class AuthorAdmin(admin.ModelAdmin):
    list_display = ('name', 'email', 'article_count', 'created_at')
    search_fields = ('name', 'email')
    inlines = [ArticleInline]

    def article_count(self, obj):
        return obj.articles.count()
    article_count.short_description = 'Articles'

@admin.register(Article)
class ArticleAdmin(admin.ModelAdmin):
    list_display = ('title', 'author', 'published', 'views', 'created_at')
    list_filter = ('published', 'created_at', 'author')
    search_fields = ('title', 'body')
    list_editable = ('published',)
    prepopulated_fields = {'slug': ('title',)}  # auto-fill slug from title
    date_hierarchy = 'created_at'
    ordering = ('-created_at',)

    fieldsets = (
        (None, {
            'fields': ('title', 'slug', 'author')
        }),
        ('Content', {
            'fields': ('body', 'tags'),
            'classes': ('wide',),
        }),
        ('Publishing', {
            'fields': ('published', 'views'),
            'classes': ('collapse',),  # collapsible section
        }),
    )

    readonly_fields = ('views', 'created_at', 'updated_at')
    filter_horizontal = ('tags',)  # nice M2M widget

    # Custom bulk action
    @admin.action(description='Mark selected as published')
    def make_published(self, request, queryset):
        count = queryset.update(published=True)
        self.message_user(request, f'{count} articles published.')

    actions = [make_published]

    # Custom queryset (e.g., add annotations)
    def get_queryset(self, request):
        qs = super().get_queryset(request)
        return qs.select_related('author')

@admin.register(Tag)
class TagAdmin(admin.ModelAdmin):
    list_display = ('name',)
    search_fields = ('name',)

# Customize admin site header
admin.site.site_header = 'My App Admin'
admin.site.site_title = 'Admin Portal'
admin.site.index_title = 'Dashboard'

Key Points

•list_display, list_filter, search_fields for list page customization
•fieldsets for grouping fields; inlines for editing related models
•Custom actions for bulk operations on selected items
•prepopulated_fields auto-fills fields based on other fields

Gotchas

•list_editable fields must also be in list_display
•list_display can include model methods but they are read-only
•The first field in list_display becomes the link to the edit page (unless list_display_links is set)
•Admin is meant for trusted users -- do not expose it as a public-facing interface

Register models with @admin.register(Model). Customize with list_display, list_filter, search_fields, fieldsets, inlines, and custom actions.

•list_display, list_filter, search_fields for customization
•inlines for related model editing

@admin.register(Article)
class ArticleAdmin(admin.ModelAdmin):
    list_display = ('title', 'author', 'published')
    list_filter = ('published',)
    search_fields = ('title',)
    list_editable = ('published',)

Admin is for trusted users only -- not a public interface

Question 9 / 20

What are Django signals and when should you use them?

Django signals allow decoupled applications to get notified when certain actions occur elsewhere in the framework. They implement the observer pattern.

Built-in signals:

pre_save / post_save: Before/after model save
pre_delete / post_delete: Before/after model delete
m2m_changed: ManyToMany field modified
request_started / request_finished: HTTP request lifecycle
user_logged_in / user_logged_out: Auth events

When to use signals:

Cross-app communication without direct imports
Reacting to third-party app events
Logging/auditing

When NOT to use signals:

Within the same app -- call the function directly
Complex business logic -- use services instead
Signals make code harder to follow ("spooky action at a distance")

Pseudo Code

@receiver(post_save, sender=User)
def on_user_created(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

Code

from django.db.models.signals import post_save, pre_save, post_delete
from django.dispatch import receiver
from django.contrib.auth.models import User

# Auto-create profile when user is created
@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

@receiver(post_save, sender=User)
def save_user_profile(sender, instance, **kwargs):
    instance.profile.save()

# Logging signal
@receiver(post_delete, sender=Article)
def log_article_deletion(sender, instance, **kwargs):
    import logging
    logger = logging.getLogger(__name__)
    logger.info(f'Article deleted: {instance.title} (id={instance.pk})')

# Pre-save validation
@receiver(pre_save, sender=Article)
def auto_slug(sender, instance, **kwargs):
    if not instance.slug:
        from django.utils.text import slugify
        instance.slug = slugify(instance.title)

# Custom signal
from django.dispatch import Signal

order_completed = Signal()  # custom signal

# Send signal
def complete_order(order):
    order.status = 'completed'
    order.save()
    order_completed.send(sender=order.__class__, order=order)

# Receive custom signal
@receiver(order_completed)
def send_order_email(sender, order, **kwargs):
    print(f'Sending email for order {order.id}')

@receiver(order_completed)
def update_inventory(sender, order, **kwargs):
    print(f'Updating inventory for order {order.id}')

# Register signals in apps.py (recommended)
# myapp/apps.py
from django.apps import AppConfig

class MyappConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'myapp'

    def ready(self):
        import myapp.signals  # register signal handlers

Key Points

•@receiver(signal, sender=Model) connects handlers to signals
•post_save with created=True for one-time setup on object creation
•Custom signals with Signal() for app-specific events
•Register signals in AppConfig.ready() method

Gotchas

•Signal handlers run synchronously -- slow handlers slow down the request
•Signals make code flow harder to trace (implicit coupling)
•post_save fires for EVERY save, not just user-initiated ones (migrations, fixtures, etc.)
•Avoid heavy logic in signals -- use Celery tasks for async work

Signals notify decoupled code when events occur. @receiver(post_save, sender=Model) runs after save. Register in AppConfig.ready(). Avoid for same-app logic -- call functions directly.

•post_save/pre_save for model lifecycle events
•Register in AppConfig.ready()

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=User)
def on_user_created(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

Signals run synchronously -- keep handlers fast

Question 10 / 20

How does Django middleware work?

Django middleware is a framework of hooks into Django's request/response processing. Each middleware component is a class that processes requests and responses globally.

Processing order:

Request phase: middleware classes are called top-to-bottom (as listed in MIDDLEWARE)
View is executed
Response phase: middleware classes are called bottom-to-top (reverse order)

Middleware hooks:

__init__(get_response): One-time setup
__call__(request): Called on every request
process_view(request, view_func, view_args, view_kwargs): Before view
process_exception(request, exception): On unhandled exceptions
process_template_response(request, response): For TemplateResponse

Pseudo Code

Request flow:
  MIDDLEWARE[0].__call__  (top)
  MIDDLEWARE[1].__call__
  MIDDLEWARE[2].__call__  (bottom)
  -> view executes
  MIDDLEWARE[2].__call__  (bottom)
  MIDDLEWARE[1].__call__
  MIDDLEWARE[0].__call__  (top)
Response returned

Code

import time
import logging

logger = logging.getLogger(__name__)

# Simple middleware (function-based pattern)
class RequestTimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration

    def __call__(self, request):
        # Before view
        start = time.perf_counter()

        response = self.get_response(request)  # call next middleware/view

        # After view
        duration = time.perf_counter() - start
        response['X-Response-Time'] = f'{duration:.4f}s'
        logger.info(f'{request.method} {request.path} - {duration:.4f}s')
        return response

# Authentication middleware
class APIKeyMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        if request.path.startswith('/api/'):
            api_key = request.headers.get('X-API-Key')
            if not api_key:
                from django.http import JsonResponse
                return JsonResponse({'error': 'API key required'}, status=401)
            request.api_key = api_key  # attach to request

        return self.get_response(request)

# Exception handling middleware
class ExceptionLoggingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        return self.get_response(request)

    def process_exception(self, request, exception):
        logger.error(
            f'Unhandled exception on {request.path}: {exception}',
            exc_info=True
        )
        return None  # let Django handle it

# CORS middleware (simplified)
class SimpleCORSMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)
        response['Access-Control-Allow-Origin'] = '*'
        response['Access-Control-Allow-Methods'] = 'GET, POST, PUT, DELETE'
        response['Access-Control-Allow-Headers'] = 'Content-Type, Authorization'
        return response

# settings.py -- order matters!
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'myapp.middleware.SimpleCORSMiddleware',        # custom
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'myapp.middleware.RequestTimingMiddleware',      # custom
    'myapp.middleware.APIKeyMiddleware',             # custom
    'django.contrib.messages.middleware.MessageMiddleware',
]

Key Points

•Middleware processes every request/response globally
•Order in MIDDLEWARE setting matters: request top-down, response bottom-up
•Return response early from __call__ to short-circuit (skip view)
•process_exception handles unhandled exceptions

Gotchas

•MIDDLEWARE order is critical -- SessionMiddleware must come before AuthenticationMiddleware
•Returning a response from __call__ before get_response() skips the view and remaining middleware
•Middleware runs for EVERY request including static files in development
•process_exception only catches exceptions from the view, not from other middleware

Middleware hooks into every request/response. Create a class with __init__(get_response) and __call__(request). Code before get_response(request) runs pre-view; code after runs post-view. Order in MIDDLEWARE matters.

•Processes every request/response globally
•Order in MIDDLEWARE setting is critical

class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        import time
        start = time.time()
        response = self.get_response(request)
        response['X-Time'] = f'{time.time() - start:.4f}s'
        return response

SessionMiddleware must come before AuthenticationMiddleware

Question 11 / 20

How do Django forms and ModelForms work?

Django forms handle HTML form rendering, input validation, and data cleaning.

Form types:

forms.Form: Manual field definition
forms.ModelForm: Auto-generated from a model (CRUD)

Validation flow:

form.is_valid() triggers validation
Each field runs its validators
clean_<fieldname>() runs for per-field custom validation
clean() runs for cross-field validation
Cleaned data available in form.cleaned_data

Pseudo Code

class ArticleForm(forms.ModelForm):
    class Meta:
        model = Article
        fields = ['title', 'body']

    def clean_title(self):
        title = self.cleaned_data['title']
        if 'spam' in title.lower():
            raise ValidationError('No spam!')
        return title

Code

from django import forms
from django.core.exceptions import ValidationError

# Regular Form
class ContactForm(forms.Form):
    name = forms.CharField(max_length=100)
    email = forms.EmailField()
    message = forms.CharField(widget=forms.Textarea)
    priority = forms.ChoiceField(choices=[
        ('low', 'Low'), ('medium', 'Medium'), ('high', 'High')
    ])

    def clean_message(self):
        message = self.cleaned_data['message']
        if len(message) < 20:
            raise ValidationError('Message must be at least 20 characters.')
        return message

# ModelForm (auto-generated from model)
class ArticleForm(forms.ModelForm):
    class Meta:
        model = Article
        fields = ['title', 'body', 'published', 'tags']
        widgets = {
            'body': forms.Textarea(attrs={'rows': 10, 'class': 'editor'}),
            'title': forms.TextInput(attrs={'placeholder': 'Enter title'}),
        }
        labels = {
            'published': 'Publish immediately',
        }

    def clean_title(self):
        title = self.cleaned_data['title']
        if Article.objects.filter(title=title).exclude(pk=self.instance.pk).exists():
            raise ValidationError('An article with this title already exists.')
        return title

    def clean(self):
        cleaned_data = super().clean()
        title = cleaned_data.get('title', '')
        body = cleaned_data.get('body', '')
        if title and body and title.lower() in body.lower()[:50]:
            raise ValidationError('Body should not start with the title.')
        return cleaned_data

# View using form
def create_article(request):
    if request.method == 'POST':
        form = ArticleForm(request.POST)
        if form.is_valid():
            article = form.save(commit=False)
            article.author = request.user
            article.save()
            form.save_m2m()  # save M2M relationships after commit=False
            return redirect('article-detail', pk=article.pk)
    else:
        form = ArticleForm()
    return render(request, 'articles/form.html', {'form': form})

# Update view
def update_article(request, pk):
    article = get_object_or_404(Article, pk=pk)
    form = ArticleForm(request.POST or None, instance=article)
    if form.is_valid():
        form.save()
        return redirect('article-detail', pk=pk)
    return render(request, 'articles/form.html', {'form': form})

# Template rendering
TEMPLATE = '''
<form method="post">
    {% csrf_token %}
    {{ form.as_p }}  {# or form.as_table, form.as_ul #}
    <button type="submit">Save</button>
</form>

{# Manual field rendering #}
<form method="post">
    {% csrf_token %}
    {% for field in form %}
        <div class="field {% if field.errors %}has-error{% endif %}">
            {{ field.label_tag }}
            {{ field }}
            {% for error in field.errors %}
                <span class="error">{{ error }}</span>
            {% endfor %}
        </div>
    {% endfor %}
    {{ form.non_field_errors }}
    <button>Save</button>
</form>
'''

Key Points

•ModelForm auto-generates fields from model; Form for custom fields
•is_valid() triggers validation; cleaned_data holds validated values
•clean_<field>() for per-field validation; clean() for cross-field
•save(commit=False) to modify before saving; save_m2m() for M2M after

Gotchas

•Must call form.save_m2m() when using save(commit=False) with M2M fields
•{% csrf_token %} is required in templates or POST will be rejected
•form.errors is populated only after is_valid() is called
•ModelForm fields list should use allowlist (fields) not blocklist (exclude) for security

Django forms validate input. ModelForm auto-generates from models. is_valid() triggers validation. clean_field() for per-field, clean() for cross-field validation.

•ModelForm for CRUD, Form for custom
•clean_<field> for per-field validation

class ArticleForm(forms.ModelForm):
    class Meta:
        model = Article
        fields = ['title', 'body']

    def clean_title(self):
        title = self.cleaned_data['title']
        if len(title) < 5:
            raise ValidationError('Too short')
        return title

Must call save_m2m() after save(commit=False) with M2M fields

Question 12 / 20

How does Django's authentication system work?

Django provides a built-in authentication system in django.contrib.auth with:

User model:

User model with username, email, password, is_staff, is_active, is_superuser
Password hashing (PBKDF2 by default)
Custom user model via AUTH_USER_MODEL

Views and decorators:

login(), logout(), authenticate() functions
@login_required decorator
LoginRequiredMixin for CBVs
Built-in views: login, logout, password change/reset

Permissions:

Model-level: add, change, delete, view per model
@permission_required('app.can_publish')
Groups for role-based access

Pseudo Code

# Authenticate
user = authenticate(username='alice', password='secret')
if user:
    login(request, user)

# Protect views
@login_required
def protected_view(request):
    ...

# Check permissions
if request.user.has_perm('blog.add_article'):
    ...

Code

from django.contrib.auth import authenticate, login, logout
from django.contrib.auth.decorators import login_required, permission_required
from django.contrib.auth.mixins import LoginRequiredMixin, PermissionRequiredMixin
from django.contrib.auth.models import User
from django.shortcuts import render, redirect

# Login view
def login_view(request):
    if request.method == 'POST':
        username = request.POST['username']
        password = request.POST['password']
        user = authenticate(request, username=username, password=password)
        if user is not None:
            login(request, user)
            next_url = request.GET.get('next', '/')
            return redirect(next_url)
        else:
            return render(request, 'login.html', {'error': 'Invalid credentials'})
    return render(request, 'login.html')

# Logout view
def logout_view(request):
    logout(request)
    return redirect('login')

# Protected views
@login_required(login_url='/login/')
def dashboard(request):
    return render(request, 'dashboard.html', {'user': request.user})

@permission_required('blog.add_article', raise_exception=True)
def create_article(request):
    pass

# CBV with auth
class ArticleCreateView(LoginRequiredMixin, PermissionRequiredMixin, CreateView):
    model = Article
    fields = ['title', 'body']
    permission_required = 'blog.add_article'

# Custom User Model (recommended for new projects)
from django.contrib.auth.models import AbstractUser

class CustomUser(AbstractUser):
    bio = models.TextField(blank=True)
    avatar = models.ImageField(upload_to='avatars/', blank=True)

# settings.py
# AUTH_USER_MODEL = 'myapp.CustomUser'  # must set BEFORE first migration

# Built-in URL patterns
from django.contrib.auth import views as auth_views

urlpatterns = [
    path('login/', auth_views.LoginView.as_view(), name='login'),
    path('logout/', auth_views.LogoutView.as_view(), name='logout'),
    path('password-change/', auth_views.PasswordChangeView.as_view(),
         name='password_change'),
    path('password-change/done/', auth_views.PasswordChangeDoneView.as_view(),
         name='password_change_done'),
]

# In templates
# {% if user.is_authenticated %}
#     Welcome, {{ user.username }}!
# {% endif %}

Key Points

•authenticate() checks credentials; login()/logout() manage sessions
•@login_required for FBVs; LoginRequiredMixin for CBVs
•Custom user model via AUTH_USER_MODEL (set before first migration)
•Built-in views for login, logout, password change/reset

Gotchas

•AUTH_USER_MODEL must be set BEFORE running the first migration -- cannot change later easily
•Always use get_user_model() or settings.AUTH_USER_MODEL instead of importing User directly
•authenticate() returns None for inactive users by default
•Login redirect defaults to /accounts/profile/ -- set LOGIN_REDIRECT_URL in settings

authenticate() checks credentials, login()/logout() manage sessions. @login_required protects views. Always define a custom user model with AUTH_USER_MODEL before the first migration.

•authenticate + login/logout for session management
•Custom User model before first migration

from django.contrib.auth import authenticate, login

def login_view(request):
    user = authenticate(request, username='alice', password='secret')
    if user:
        login(request, user)
        return redirect('/')

@login_required
def protected(request):
    return render(request, 'page.html')

AUTH_USER_MODEL must be set before first migration

Question 13 / 20

What is Django REST Framework (DRF) and how does it work?

Django REST Framework (DRF) is a toolkit for building Web APIs in Django. It provides:

Key components:

Serializers: Convert models to/from JSON (like forms for APIs)
ViewSets: Group related views (list, create, retrieve, update, delete)
Routers: Auto-generate URL patterns from ViewSets
Authentication: Token, Session, JWT (via extension)
Permissions: IsAuthenticated, IsAdminUser, custom permissions
Pagination: PageNumber, LimitOffset, Cursor
Browsable API: Interactive HTML API documentation

Pseudo Code

serializer -> converts Model <-> JSON
viewset -> handles CRUD operations
router -> auto-generates URL patterns

class ArticleSerializer(ModelSerializer):
    class Meta:
        model = Article
        fields = '__all__'

class ArticleViewSet(ModelViewSet):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer

Code

from rest_framework import serializers, viewsets, permissions, status
from rest_framework.decorators import api_view, action
from rest_framework.response import Response
from rest_framework.routers import DefaultRouter

# Serializer
class ArticleSerializer(serializers.ModelSerializer):
    author_name = serializers.CharField(source='author.name', read_only=True)

    class Meta:
        model = Article
        fields = ['id', 'title', 'body', 'author', 'author_name',
                  'published', 'views', 'created_at']
        read_only_fields = ['views', 'created_at']

    def validate_title(self, value):
        if len(value) < 5:
            raise serializers.ValidationError('Title must be at least 5 characters.')
        return value

# ViewSet (all CRUD in one class)
class ArticleViewSet(viewsets.ModelViewSet):
    queryset = Article.objects.select_related('author').all()
    serializer_class = ArticleSerializer
    permission_classes = [permissions.IsAuthenticatedOrReadOnly]

    def perform_create(self, serializer):
        serializer.save(author=self.request.user)

    def get_queryset(self):
        qs = super().get_queryset()
        published = self.request.query_params.get('published')
        if published is not None:
            qs = qs.filter(published=published == 'true')
        return qs

    @action(detail=True, methods=['post'])
    def publish(self, request, pk=None):
        article = self.get_object()
        article.published = True
        article.save()
        return Response({'status': 'published'})

# Function-based API view
@api_view(['GET', 'POST'])
def article_list(request):
    if request.method == 'GET':
        articles = Article.objects.all()
        serializer = ArticleSerializer(articles, many=True)
        return Response(serializer.data)
    elif request.method == 'POST':
        serializer = ArticleSerializer(data=request.data)
        if serializer.is_valid():
            serializer.save()
            return Response(serializer.data, status=status.HTTP_201_CREATED)
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)

# Router (auto-generates URLs)
router = DefaultRouter()
router.register(r'articles', ArticleViewSet)

# urls.py
from django.urls import path, include

urlpatterns = [
    path('api/', include(router.urls)),
    # Generates:
    # GET/POST   /api/articles/
    # GET/PUT/DELETE /api/articles/{pk}/
    # POST /api/articles/{pk}/publish/  (custom action)
]

# settings.py
REST_FRAMEWORK = {
    'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.PageNumberPagination',
    'PAGE_SIZE': 10,
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.TokenAuthentication',
    ],
}

Key Points

•Serializers convert models to/from JSON with validation
•ModelViewSet provides all CRUD operations in one class
•Routers auto-generate URL patterns from ViewSets
•@action decorator for custom endpoints on ViewSets

Gotchas

•DRF must be added to INSTALLED_APPS as 'rest_framework'
•perform_create/perform_update hooks let you modify save behavior
•Nested serializers can cause N+1 queries -- use select_related in get_queryset
•DRF's Response is different from Django's HttpResponse/JsonResponse

DRF: Serializer for model-JSON conversion, ViewSet for CRUD endpoints, Router for auto-URL generation. ModelSerializer + ModelViewSet = full API with minimal code.

•Serializer + ViewSet + Router = full CRUD API
•ModelSerializer auto-generates fields from model

from rest_framework import serializers, viewsets
from rest_framework.routers import DefaultRouter

class ArticleSerializer(serializers.ModelSerializer):
    class Meta:
        model = Article
        fields = '__all__'

class ArticleViewSet(viewsets.ModelViewSet):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer

router = DefaultRouter()
router.register('articles', ArticleViewSet)

Add 'rest_framework' to INSTALLED_APPS

Question 14 / 20

How do you write management commands in Django?

Django management commands are custom CLI tools accessible via python manage.py <command>. They have full access to Django's ORM and settings.

Structure:

Create a file at myapp/management/commands/mycommand.py. The class must inherit BaseCommand and implement handle().

Use cases:

Database seeding
Data import/export
Periodic tasks (cron jobs)
One-off data migrations
System health checks

Pseudo Code

myapp/
  management/
    __init__.py
    commands/
      __init__.py
      seed_data.py  <- your command

# Usage: python manage.py seed_data --count 100

Code

# myapp/management/commands/seed_data.py
from django.core.management.base import BaseCommand, CommandError
from django.utils.text import slugify
from myapp.models import Article, Author
import random

class Command(BaseCommand):
    help = 'Seed the database with sample articles'

    def add_arguments(self, parser):
        parser.add_argument('--count', type=int, default=10,
                            help='Number of articles to create')
        parser.add_argument('--clear', action='store_true',
                            help='Clear existing data first')

    def handle(self, *args, **options):
        count = options['count']
        clear = options['clear']

        if clear:
            deleted, _ = Article.objects.all().delete()
            self.stdout.write(self.style.WARNING(f'Deleted {deleted} articles'))

        # Ensure we have an author
        author, created = Author.objects.get_or_create(
            email='seed@example.com',
            defaults={'name': 'Seed Author'}
        )

        articles = []
        for i in range(count):
            title = f'Sample Article {i + 1}'
            articles.append(Article(
                title=title,
                slug=slugify(title),
                body=f'Body content for article {i + 1}.',
                author=author,
                published=random.choice([True, False]),
            ))

        Article.objects.bulk_create(articles, ignore_conflicts=True)

        self.stdout.write(
            self.style.SUCCESS(f'Successfully created {count} articles')
        )

# Usage:
# python manage.py seed_data
# python manage.py seed_data --count 50
# python manage.py seed_data --clear --count 20

# Another example: health check command
# myapp/management/commands/healthcheck.py
from django.core.management.base import BaseCommand
from django.db import connection

class Command(BaseCommand):
    help = 'Check system health'

    def handle(self, *args, **options):
        # Database check
        try:
            with connection.cursor() as cursor:
                cursor.execute('SELECT 1')
            self.stdout.write(self.style.SUCCESS('Database: OK'))
        except Exception as e:
            raise CommandError(f'Database: FAILED - {e}')

        self.stdout.write(self.style.SUCCESS('All checks passed'))

Key Points

•Create at myapp/management/commands/<name>.py with Command class
•add_arguments() for CLI options; handle() for logic
•self.stdout.write with self.style.SUCCESS/WARNING/ERROR for output
•CommandError for fatal errors that should stop execution

Gotchas

•Both management/ and commands/ directories need __init__.py files
•The filename IS the command name: seed_data.py -> python manage.py seed_data
•Commands run with full Django setup -- ORM, settings, etc. are available
•Use self.stdout.write instead of print() for proper output handling

Create myapp/management/commands/mycommand.py with a Command class extending BaseCommand. Implement handle() for logic, add_arguments() for CLI options.

•File at management/commands/<name>.py
•BaseCommand subclass with handle() method

# myapp/management/commands/seed.py
from django.core.management.base import BaseCommand

class Command(BaseCommand):
    help = 'Seed database'

    def add_arguments(self, parser):
        parser.add_argument('--count', type=int, default=10)

    def handle(self, *args, **options):
        self.stdout.write(self.style.SUCCESS(f'Created {options["count"]} items'))

Both management/ and commands/ need __init__.py

Question 15 / 20

How do you test Django applications?

Django provides django.test.TestCase which wraps each test in a transaction that is rolled back, keeping the database clean between tests.

Key test classes:

TestCase: DB access with transaction rollback (most common)
TransactionTestCase: Real transactions (for testing transaction behavior)
SimpleTestCase: No DB access (fastest)
LiveServerTestCase: Starts a real server (for Selenium)

Test client:

self.client makes HTTP requests without a real server.

Pseudo Code

class TestArticleAPI(TestCase):
    def setUp(self):
        self.user = User.objects.create_user('test', password='pass')
        self.client.login(username='test', password='pass')

    def test_create_article(self):
        response = self.client.post('/api/articles/', {...})
        self.assertEqual(response.status_code, 201)

Code

from django.test import TestCase, Client
from django.contrib.auth.models import User
from django.urls import reverse
from .models import Article, Author

class ArticleModelTest(TestCase):
    def setUp(self):
        self.author = Author.objects.create(name='Alice', email='a@test.com')
        self.article = Article.objects.create(
            title='Test Article',
            slug='test-article',
            body='Test body',
            author=self.author,
            published=True,
        )

    def test_str_representation(self):
        self.assertEqual(str(self.article), 'Test Article')

    def test_article_creation(self):
        self.assertEqual(Article.objects.count(), 1)
        self.assertEqual(self.article.author.name, 'Alice')

class ArticleViewTest(TestCase):
    def setUp(self):
        self.client = Client()
        self.user = User.objects.create_user(
            username='testuser', password='testpass'
        )
        self.author = Author.objects.create(name='Test', email='t@test.com')
        self.article = Article.objects.create(
            title='Test', slug='test', body='Body',
            author=self.author, published=True,
        )

    def test_article_list_view(self):
        url = reverse('article-list')
        response = self.client.get(url)
        self.assertEqual(response.status_code, 200)
        self.assertContains(response, 'Test')

    def test_article_detail_view(self):
        url = reverse('article-detail', kwargs={'pk': self.article.pk})
        response = self.client.get(url)
        self.assertEqual(response.status_code, 200)

    def test_create_requires_login(self):
        url = reverse('article-create')
        response = self.client.get(url)
        self.assertEqual(response.status_code, 302)  # redirect to login

    def test_create_article(self):
        self.client.login(username='testuser', password='testpass')
        url = reverse('article-create')
        response = self.client.post(url, {
            'title': 'New Article',
            'body': 'New body content',
            'published': True,
        })
        self.assertEqual(response.status_code, 302)  # redirect on success
        self.assertTrue(Article.objects.filter(title='New Article').exists())

    def test_article_api_json(self):
        response = self.client.get('/api/articles/',
                                    content_type='application/json')
        self.assertEqual(response.status_code, 200)
        data = response.json()
        self.assertEqual(len(data['results']), 1)

# Using pytest with Django (pytest-django)
import pytest

@pytest.fixture
def author(db):
    return Author.objects.create(name='Alice', email='a@test.com')

@pytest.fixture
def article(author):
    return Article.objects.create(
        title='Test', slug='test', body='Body',
        author=author, published=True,
    )

def test_article_str(article):
    assert str(article) == 'Test'

@pytest.mark.django_db
def test_article_count(article):
    assert Article.objects.count() == 1

# Run: python manage.py test
# Or: pytest (with pytest-django)

Key Points

•TestCase wraps each test in a transaction rollback (clean DB per test)
•self.client makes HTTP requests without a real server
•setUp() creates test data; it runs before each test method
•pytest-django with @pytest.mark.django_db for pytest-style tests

Gotchas

•TestCase rollback means data from one test is not visible in another
•self.client.login() requires the user to have a usable password (create_user, not create)
•assertContains checks response body; response.json() for API responses
•Django test runner uses a separate test database (test_<dbname>)

django.test.TestCase provides transaction rollback per test. self.client makes HTTP requests. Use setUp() for test data. Run with python manage.py test or pytest.

•TestCase with transaction rollback
•self.client for HTTP testing

from django.test import TestCase

class ArticleTest(TestCase):
    def setUp(self):
        self.article = Article.objects.create(title='Test', slug='test')

    def test_list_view(self):
        response = self.client.get('/articles/')
        self.assertEqual(response.status_code, 200)
        self.assertContains(response, 'Test')

Django uses a separate test database

Question 16 / 20

How does Django caching work?

Django provides a flexible caching framework with multiple backends and granularity levels.

Cache backends:

Memcached: High-performance, distributed
Redis: Feature-rich, persistent
Database: Uses a DB table
File-based: Filesystem cache
Local memory: Per-process (default, not for production)
Dummy: No-op for development

Caching levels:

Per-site cache: Middleware caches entire site
Per-view cache: @cache_page(60) decorator
Template fragment: {% cache %} template tag
Low-level API: cache.get(), cache.set() for fine control

Pseudo Code

# Per-view: cache for 60 seconds
@cache_page(60)
def my_view(request): ...

# Low-level API
cache.set('key', value, timeout=300)
value = cache.get('key', default=None)
cache.delete('key')

Code

from django.views.decorators.cache import cache_page
from django.core.cache import cache
from django.views.decorators.vary import vary_on_cookie

# settings.py
CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379/1',
        'TIMEOUT': 300,  # 5 minutes default
    }
}

# Per-view caching
@cache_page(60 * 15)  # cache for 15 minutes
def article_list(request):
    articles = Article.objects.filter(published=True)
    return render(request, 'articles/list.html', {'articles': articles})

# Vary cache by cookie (different cache per user)
@vary_on_cookie
@cache_page(60 * 10)
def user_dashboard(request):
    return render(request, 'dashboard.html')

# Low-level cache API
def get_popular_articles():
    cache_key = 'popular_articles'
    articles = cache.get(cache_key)
    if articles is None:
        articles = list(
            Article.objects.filter(published=True)
            .order_by('-views')[:10]
            .values('id', 'title', 'views')
        )
        cache.set(cache_key, articles, timeout=60 * 5)  # 5 minutes
    return articles

# Cache invalidation
def update_article(request, pk):
    article = Article.objects.get(pk=pk)
    article.title = request.POST['title']
    article.save()
    cache.delete('popular_articles')  # invalidate cache
    cache.delete(f'article_{pk}')     # invalidate specific
    return redirect('article-detail', pk=pk)

# get_or_set (atomic get-or-compute)
def get_stats():
    return cache.get_or_set(
        'site_stats',
        lambda: {
            'articles': Article.objects.count(),
            'authors': Author.objects.count(),
        },
        timeout=60 * 30
    )

# Template fragment caching
TEMPLATE = '''
{% load cache %}
{% cache 300 sidebar request.user.id %}
    {# This block is cached for 300 seconds per user #}
    <div class="sidebar">
        {% for article in popular_articles %}
            <a href="{{ article.url }}">{{ article.title }}</a>
        {% endfor %}
    </div>
{% endcache %}
'''

Key Points

•Multiple backends: Redis, Memcached, database, file, local memory
•@cache_page for view caching; cache.get/set for low-level control
•Template fragment caching with {% cache timeout name vary_args %}
•cache.get_or_set for atomic get-or-compute pattern

Gotchas

•Cache invalidation is hard -- stale data is a common bug
•Per-view cache ignores query parameters by default -- use vary_on_headers
•Local memory cache is per-process -- not shared between workers in production
•Cache keys must be strings and should include versioning for safe invalidation

Django caching: @cache_page(60) for views, cache.get()/cache.set() for low-level, {% cache %} for template fragments. Backends: Redis, Memcached, database, file.

•@cache_page for views, cache.get/set for data
•Redis or Memcached for production

from django.core.cache import cache
from django.views.decorators.cache import cache_page

@cache_page(60 * 15)  # cache view for 15 min
def my_view(request): ...

# Low-level
cache.set('key', 'value', timeout=300)
value = cache.get('key')

Cache invalidation is the hardest problem

Question 17 / 20

How do Django managers and custom querysets work?

A Manager is the interface through which database query operations are provided to models. By default, objects is the manager.

Custom Manager:

Override the default manager to add custom methods or modify the base queryset.

Custom QuerySet:

Define reusable query methods that can be chained.

The pattern:

Custom QuerySet methods are chainable: Article.objects.published().recent()
Manager methods return QuerySets or single values
Use as_manager() to create a manager from a QuerySet class

Pseudo Code

class ArticleQuerySet(QuerySet):
    def published(self):
        return self.filter(published=True)
    def recent(self):
        return self.order_by('-created_at')

class ArticleManager(Manager):
    def get_queryset(self):
        return ArticleQuerySet(self.model, using=self._db)

# Usage: Article.objects.published().recent()[:10]

Code

from django.db import models
from django.db.models import QuerySet, Manager, Count

# Custom QuerySet with chainable methods
class ArticleQuerySet(QuerySet):
    def published(self):
        return self.filter(published=True)

    def draft(self):
        return self.filter(published=False)

    def recent(self, days=7):
        from django.utils import timezone
        from datetime import timedelta
        cutoff = timezone.now() - timedelta(days=days)
        return self.filter(created_at__gte=cutoff)

    def popular(self, min_views=100):
        return self.filter(views__gte=min_views)

    def by_author(self, author_name):
        return self.filter(author__name=author_name)

    def with_comment_count(self):
        return self.annotate(comment_count=Count('comments'))

# Custom Manager
class ArticleManager(Manager):
    def get_queryset(self):
        return ArticleQuerySet(self.model, using=self._db)

    # Proxy chainable methods
    def published(self):
        return self.get_queryset().published()

    def draft(self):
        return self.get_queryset().draft()

    def recent(self, days=7):
        return self.get_queryset().recent(days)

# Model
class Article(models.Model):
    title = models.CharField(max_length=200)
    body = models.TextField()
    published = models.BooleanField(default=False)
    views = models.PositiveIntegerField(default=0)
    author = models.ForeignKey('Author', on_delete=models.CASCADE)
    created_at = models.DateTimeField(auto_now_add=True)

    # Option 1: Custom manager
    objects = ArticleManager()

    # Option 2: Use QuerySet.as_manager() (simpler)
    # objects = ArticleQuerySet.as_manager()

# Usage: all methods are chainable!
Article.objects.published().recent(30).popular(50)
Article.objects.draft().by_author('Alice')
Article.objects.published().with_comment_count().order_by('-comment_count')

# Manager that changes default queryset
class PublishedManager(Manager):
    def get_queryset(self):
        return super().get_queryset().filter(published=True)

class Article(models.Model):
    # ...
    objects = ArticleManager()      # default: all articles
    published = PublishedManager()  # only published

# Article.objects.all()       -> all articles
# Article.published.all()     -> only published articles
# Article.published.recent()  -> published + recent

Key Points

•Custom QuerySet for chainable, reusable query methods
•Custom Manager to modify the default queryset or add methods
•QuerySet.as_manager() creates a manager from a QuerySet class automatically
•Multiple managers on one model (objects for all, published for filtered)

Gotchas

•Custom manager's get_queryset() affects admin, related managers, and everything using that manager
•If you override the default manager, ensure it returns all objects or admin will be filtered
•Django uses the first manager defined as the default_manager (affects admin and related lookups)
•QuerySet methods must return self (the queryset) to be chainable

Custom QuerySet for chainable query methods (published().recent()). Custom Manager to modify the default queryset. Use QuerySet.as_manager() for automatic manager creation.

•QuerySet methods for chainable queries
•as_manager() for automatic manager creation

class ArticleQuerySet(models.QuerySet):
    def published(self):
        return self.filter(published=True)
    def recent(self):
        return self.order_by('-created_at')

class Article(models.Model):
    objects = ArticleQuerySet.as_manager()

# Usage: Article.objects.published().recent()[:5]

Default manager affects admin and related lookups

Question 18 / 20

How do you handle static files in Django?

Django handles static files (CSS, JS, images) differently in development and production.

Development:

django.contrib.staticfiles serves files from each app's static/ directory
STATIC_URL defines the URL prefix (default: /static/)
runserver serves static files automatically

Production:

python manage.py collectstatic copies all static files to STATIC_ROOT
Nginx/Apache serves from STATIC_ROOT directly
Django does NOT serve static files in production (use WhiteNoise or a web server)

Media files (user uploads):

MEDIA_URL and MEDIA_ROOT for user-uploaded files
Served separately from static files

Pseudo Code

Development:
  App static files: myapp/static/myapp/style.css
  Template: {% static 'myapp/style.css' %}
  Served by runserver

Production:
  collectstatic -> copies to STATIC_ROOT
  Nginx serves STATIC_ROOT at STATIC_URL

Code

# settings.py
import os
from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent

# Static files (CSS, JavaScript, images)
STATIC_URL = '/static/'
STATIC_ROOT = BASE_DIR / 'staticfiles'  # collectstatic output
STATICFILES_DIRS = [
    BASE_DIR / 'static',  # project-level static files
]

# Media files (user uploads)
MEDIA_URL = '/media/'
MEDIA_ROOT = BASE_DIR / 'media'

# Template usage
TEMPLATE = '''
{% load static %}
<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" href="{% static 'myapp/css/style.css' %}">
</head>
<body>
    <img src="{% static 'myapp/images/logo.png' %}" alt="Logo">
    <script src="{% static 'myapp/js/app.js' %}"></script>
</body>
</html>
'''

# urls.py (for development only)
from django.conf import settings
from django.conf.urls.static import static

urlpatterns = [
    # ... your URL patterns
]

# Serve media files in development
if settings.DEBUG:
    urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

# Production: collectstatic
# python manage.py collectstatic
# Copies all static files to STATIC_ROOT

# WhiteNoise for simple production setup
# pip install whitenoise
# settings.py:
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',  # add after SecurityMiddleware
    # ...
]
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

# File structure
# myapp/static/myapp/
#   css/style.css
#   js/app.js
#   images/logo.png

Key Points

•{% load static %} + {% static 'path' %} in templates
•collectstatic gathers all static files into STATIC_ROOT for production
•STATICFILES_DIRS for project-level (non-app) static files
•WhiteNoise or Nginx for serving static files in production

Gotchas

•Never serve static files with Django in production (DEBUG=False disables it)
•Namespace static files: myapp/static/myapp/ to avoid collisions between apps
•collectstatic overwrites STATIC_ROOT -- don't put source files there
•Media files need separate URL config for development

{% static 'app/file.css' %} in templates. collectstatic gathers files for production. Use WhiteNoise or Nginx to serve. Namespace: app/static/app/.

•{% static %} for URLs, collectstatic for production
•Namespace with app/static/app/

# settings.py
STATIC_URL = '/static/'
STATIC_ROOT = BASE_DIR / 'staticfiles'

# template: {% load static %}
# <link href="{% static 'myapp/style.css' %}">

# production: python manage.py collectstatic

Django does not serve static files when DEBUG=False

Question 19 / 20

What are Django model managers, select_related, and prefetch_related?

The N+1 query problem:

When accessing related objects in a loop, Django makes a separate query for each object -- 1 query for the list + N queries for related objects = N+1 queries.

Solutions:

select_related(*fields): Uses SQL JOIN for ForeignKey/OneToOne (single query)
prefetch_related(*fields): Uses separate query + Python join for ManyToMany/reverse FK (2 queries)

When to use which:

select_related: ForeignKey, OneToOneField (forward relations)
prefetch_related: ManyToManyField, reverse ForeignKey (backward relations), GenericRelation

Pseudo Code

N+1 problem:
  articles = Article.objects.all()   # 1 query
  for a in articles:
      print(a.author.name)           # N queries (one per article!)

Fix with select_related:
  articles = Article.objects.select_related('author')  # 1 JOIN query
  for a in articles:
      print(a.author.name)           # 0 extra queries

Fix with prefetch_related:
  articles = Article.objects.prefetch_related('tags')   # 2 queries total
  for a in articles:
      print(a.tags.all())            # 0 extra queries

Code

from django.db.models import Prefetch, Count

# N+1 problem (BAD)
articles = Article.objects.all()
for article in articles:
    # Each access triggers a separate query!
    print(f"{article.title} by {article.author.name}")
    for tag in article.tags.all():
        print(f"  Tag: {tag.name}")
# Total queries: 1 + N (authors) + N (tags) = 2N + 1

# select_related for ForeignKey (SQL JOIN)
articles = Article.objects.select_related('author').all()
for article in articles:
    print(f"{article.title} by {article.author.name}")  # no extra query
# Total queries: 1 (JOIN)

# Nested select_related
articles = Article.objects.select_related('author__profile').all()
# JOINs article -> author -> profile in one query

# prefetch_related for ManyToMany and reverse FK
articles = Article.objects.prefetch_related('tags').all()
for article in articles:
    for tag in article.tags.all():  # no extra query
        print(tag.name)
# Total queries: 2 (articles + tags)

# Combine both
articles = (Article.objects
    .select_related('author')
    .prefetch_related('tags', 'comments')
    .all())
# Total queries: 3 (articles+author JOIN, tags prefetch, comments prefetch)

# Custom Prefetch for filtered/annotated prefetching
recent_comments = Comment.objects.filter(created_at__gte=one_week_ago)
articles = Article.objects.prefetch_related(
    Prefetch('comments', queryset=recent_comments, to_attr='recent_comments')
).all()

for article in articles:
    for comment in article.recent_comments:  # already filtered
        print(comment.text)

# Detecting N+1 in development
# pip install django-debug-toolbar
# Shows query count and duplicates per request

# Or use django.db.connection.queries
from django.db import connection, reset_queries
from django.conf import settings

settings.DEBUG = True
reset_queries()

articles = list(Article.objects.select_related('author').all())
for a in articles:
    _ = a.author.name

print(f"Queries executed: {len(connection.queries)}")
for q in connection.queries:
    print(q['sql'][:100])

Key Points

•select_related uses SQL JOIN for ForeignKey/OneToOne (1 query)
•prefetch_related uses a separate query for M2M/reverse FK (2 queries)
•Custom Prefetch() for filtered or annotated prefetching
•django-debug-toolbar for detecting N+1 queries in development

Gotchas

•select_related follows FK chains and can create huge JOINs -- limit depth
•prefetch_related caches results -- calling .filter() on a prefetched relation ignores the cache
•Prefetch with to_attr stores results as a list attribute, not a manager
•Only() and defer() can conflict with select_related if related fields are deferred

N+1 problem: 1 query + N per related object. Fix: select_related('fk_field') for ForeignKey (SQL JOIN), prefetch_related('m2m_field') for ManyToMany (2 queries).

•select_related for FK (JOIN), prefetch_related for M2M
•Use django-debug-toolbar to detect N+1

# BAD: N+1
for a in Article.objects.all():
    print(a.author.name)  # extra query each time

# GOOD: 1 query (JOIN)
for a in Article.objects.select_related('author'):
    print(a.author.name)  # no extra query

Filtering a prefetched relation ignores the cache

Question 20 / 20

How does Django handle settings for different environments?

Django uses a single settings.py by default, but real projects need different settings for development, testing, staging, and production.

Common approaches:

Environment variables (recommended): Read settings from environment
Multiple settings files: settings/base.py, settings/dev.py, settings/prod.py
django-environ or python-decouple: Libraries for reading .env files

Key settings that change per environment:

DEBUG (True in dev, False in prod)
SECRET_KEY (unique per environment)
DATABASES (SQLite in dev, PostgreSQL in prod)
ALLOWED_HOSTS (specific domains in prod)
STATIC_ROOT / MEDIA_ROOT
Email backend, caching, logging

Pseudo Code

Approach 1: environment variables
  SECRET_KEY = os.environ.get('SECRET_KEY', 'dev-fallback')
  DEBUG = os.environ.get('DEBUG', 'True') == 'True'

Approach 2: split settings
  settings/base.py   <- shared
  settings/dev.py    <- from .base import * + dev overrides
  settings/prod.py   <- from .base import * + prod overrides
  DJANGO_SETTINGS_MODULE=myproject.settings.prod

Code

# Approach 1: Environment variables with python-decouple
# pip install python-decouple
# .env file:
# SECRET_KEY=your-secret-key
# DEBUG=True
# DATABASE_URL=sqlite:///db.sqlite3

from decouple import config, Csv
import dj_database_url

SECRET_KEY = config('SECRET_KEY')
DEBUG = config('DEBUG', default=False, cast=bool)
ALLOWED_HOSTS = config('ALLOWED_HOSTS', default='localhost', cast=Csv())

DATABASES = {
    'default': dj_database_url.config(
        default='sqlite:///db.sqlite3'
    )
}

# Approach 2: Split settings files
# settings/base.py
from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent.parent

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    # ...
]

# settings/dev.py
from .base import *

DEBUG = True
SECRET_KEY = 'dev-insecure-key'
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}
INSTALLED_APPS += ['debug_toolbar']
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'

# settings/prod.py
import os
from .base import *

DEBUG = False
SECRET_KEY = os.environ['SECRET_KEY']
ALLOWED_HOSTS = os.environ['ALLOWED_HOSTS'].split(',')
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': os.environ['DB_NAME'],
        'USER': os.environ['DB_USER'],
        'PASSWORD': os.environ['DB_PASSWORD'],
        'HOST': os.environ.get('DB_HOST', 'localhost'),
        'PORT': os.environ.get('DB_PORT', '5432'),
    }
}
STATIC_ROOT = '/var/www/static/'

# Security settings for production
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000

# settings/test.py
from .base import *

DEBUG = False
SECRET_KEY = 'test-key'
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': ':memory:',
    }
}
PASSWORD_HASHERS = ['django.contrib.auth.hashers.MD5PasswordHasher']  # faster tests

# Select settings via env:
# export DJANGO_SETTINGS_MODULE=myproject.settings.dev
# python manage.py runserver

# Or in manage.py:
# os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings.dev')

Key Points

•Environment variables for secrets (SECRET_KEY, DATABASE_URL)
•Split settings (base/dev/prod/test) for environment-specific config
•DJANGO_SETTINGS_MODULE env var selects which settings to use
•Production: DEBUG=False, HTTPS settings, strong SECRET_KEY

Gotchas

•Never commit SECRET_KEY or database passwords to version control
•DEBUG=True in production exposes sensitive information in error pages
•ALLOWED_HOSTS must be set when DEBUG=False or Django rejects all requests
•Forgetting to set DJANGO_SETTINGS_MODULE uses the default (usually dev)

Use environment variables for secrets and split settings files (base/dev/prod). Set DJANGO_SETTINGS_MODULE to select config. Never commit SECRET_KEY to version control.

•Split settings: base + dev/prod/test
•Environment variables for secrets

# settings/dev.py
from .base import *
DEBUG = True
DATABASES = {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 'db.sqlite3'}}

# settings/prod.py
from .base import *
import os
DEBUG = False
SECRET_KEY = os.environ['SECRET_KEY']

# export DJANGO_SETTINGS_MODULE=myproject.settings.prod

ALLOWED_HOSTS required when DEBUG=False

Built by onllm.dev

Home GitHub Support awesomePrep