Django Quick Reference

Analogy categoryAnalogies

This reference collects the commands, ORM patterns, and settings you'll reach for constantly once you're past the tutorial stage and actively building: scaffolding apps, managing migrations, querying the ORM efficiently, and knowing which settings control what in deployment. It's meant to be skimmed, not read start to finish — treat each subsection as a lookup table for the moment you need it.

🏏

Cricket analogy: It's like a fielding captain's laminated cheat card listing field placements for different bowlers and match situations — not something you study cover to cover mid-over, but something you glance at fast when you need it.

Common manage.py Commands

The commands you'll type dozens of times a day include python manage.py runserver to start the dev server, startapp <name> to scaffold a new app, makemigrations to detect model changes and generate migration files, migrate to apply them, createsuperuser for admin access, and shell (or shell_plus from django-extensions) to poke at the ORM interactively. Less frequent but essential commands include dumpdata/loaddata for exporting and importing fixture data, showmigrations to see which migrations are applied, and sqlmigrate <app> <migration_number> to preview the exact SQL a migration will run before you apply it against production.

🏏

Cricket analogy: makemigrations followed by migrate is like a coach first drafting the tactical changes on a whiteboard (detecting what changed) and only then actually briefing the team to execute them on the field (applying the change).

bash

# Project & app scaffolding
django-admin startproject myproject .
python manage.py startapp blog

# Migrations
python manage.py makemigrations
python manage.py migrate
python manage.py sqlmigrate blog 0003
python manage.py showmigrations

# Admin & data
python manage.py createsuperuser
python manage.py dumpdata blog.Post --indent 2 > posts.json
python manage.py loaddata posts.json

# Dev server & shell
python manage.py runserver 0.0.0.0:8000
python manage.py shell

ORM Quick Reference

Common query patterns: Model.objects.filter(field=value) for exact matches, .exclude() for negation, .get() when you expect exactly one result (raises DoesNotExist or MultipleObjectsReturned otherwise), field lookups like title__icontains="django" or created__gte=some_date for comparisons, and Q objects for OR conditions (Q(status="draft") | Q(status="review")). For performance, remember select_related/prefetch_related to avoid N+1 queries, .only()/.defer() to limit which columns are fetched, and .values()/.values_list() when you just need plain dicts or tuples instead of full model instances.

🏏

Cricket analogy: Q objects for OR conditions are like a scout's search criteria for 'find me an all-rounder who either bats above 40 average OR bowls under 25 economy' — combining two alternative conditions into one query.

Use .values_list('id', flat=True) when you only need a flat list of primary keys — it skips instantiating full model objects and is noticeably faster for large querysets used just for membership checks or bulk operations.

Settings & Deployment Cheatsheet

Quick lookups for the settings that trip people up most: DEBUG must be False in production; ALLOWED_HOSTS needs your real domain(s) listed; STATIC_URL/STATIC_ROOT control where static files are served from and collected to; DATABASES typically comes from env.db("DATABASE_URL") via django-environ; and MIDDLEWARE order matters, with SecurityMiddleware first and things like AuthenticationMiddleware needing SessionMiddleware to have already run. For a fast production readiness check, python manage.py check --deploy scans your settings and flags common misconfigurations like a missing SECURE_HSTS_SECONDS or a DEBUG=True left on.

🏏

Cricket analogy: check --deploy is like a pre-match pitch inspection by the umpires confirming the boundary ropes, sightscreens, and covers are all correctly in place before play is allowed to start.

python manage.py check --deploy only flags what it can detect from settings; it won't catch every production issue (like a missing reverse proxy or unpatched dependency), so treat it as a baseline sanity check, not a full security audit.

makemigrations detects model changes and writes migration files; migrate applies them to the database.
sqlmigrate previews the exact SQL a migration will run before applying it, useful for reviewing production changes.
Q objects combine filter conditions with OR logic; regular chained filters combine with AND logic.
select_related/prefetch_related prevent N+1 queries; .values_list(flat=True) avoids instantiating full model objects for simple lookups.
DEBUG, ALLOWED_HOSTS, STATIC_ROOT, and DATABASES are the settings most commonly misconfigured between environments.
MIDDLEWARE order matters — SecurityMiddleware should run first, and AuthenticationMiddleware depends on SessionMiddleware running earlier.
python manage.py check --deploy is a fast baseline scan for common production misconfigurations, not a full audit.