Django

A Django project is the configured site: a settings module, a root URLconf and the WSGI/ASGI entry points. An app is a Python package providing one set of features, enabled by listing it in INSTALLED_APPS; one project combines many apps.

runserver is a convenience server built on Python's wsgiref that Django never security-audited or performance-tested. Production serves the same WSGI or ASGI application object from wsgi.py or asgi.py through a dedicated application server.

DEBUG=True shows detailed tracebacks with settings and local variables, records every SQL query per connection, and trusts localhost when ALLOWED_HOSTS is empty. With DEBUG=False you must set ALLOWED_HOSTS, or every request returns 400 Bad Request.

Django's model is the data layer, its view is the Python callable that decides which data a URL returns, and its template decides how that data looks. The framework itself, routing requests through the URLconf, plays MVC's controller.

AppConfig.ready() runs after every installed app's models are loaded, so it suits startup wiring such as importing signal receivers. Avoid database queries there: ready() runs on every management command and can run more than once in tests.

include() delegates to another URLconf: Django strips the part of the path matched by the prefix, here comments/, and resolves the remainder against the app's urlpatterns. Values captured in the prefix and any extra kwargs reach every included view.

str (the default) matches one non-empty segment without a slash; int matches digits and passes an int; slug matches ASCII letters, digits, hyphens and underscores; uuid matches a lowercase dashed UUID and passes uuid.UUID; path matches anything non-empty, slashes included.

The slug route serves it: Django tries urlpatterns in list order and calls the first pattern that matches, and 'new' is a valid slug. Listing the fixed events/new/ route above the converter route fixes it.

Raising Http404 abandons the view and Django builds a 404. With DEBUG=True it shows a technical page listing the URL patterns tried; with DEBUG=False it calls handler404, which renders a 404.html template or a plain Not Found page.

In Python call django.urls.reverse('job-detail', kwargs={'pk': 42}) or args=[42]; in a template write {% url 'job-detail' pk=42 %}. Both find the route by its name= and return its path, such as /jobs/42/.

They are view decorators from django.views.decorators.http that let only the listed HTTP methods reach the view. Any other method gets an HttpResponseNotAllowed: a 405 response with an Allow header naming the permitted methods.

A Django function view takes the HttpRequest first, plus the URL's captured values as keyword arguments, and returns an HttpResponse or raises an exception Django maps to one. Returning None makes Django raise ValueError, surfacing as a 500.

Django fills request.FILES only for a POST request whose form used enctype="multipart/form-data" and actually sent a file. Without that enctype the browser sends only the file name as text, so FILES stays empty.

Function view decorators expect request as the first argument, but a method receives self first, so the decorator inspects the wrong object. method_decorator adapts the decorator to methods; apply it to dispatch() or to the class with name="dispatch".

Function views win for bespoke flows, one-off endpoints and readability; generic class-based views win when a page matches a standard list, detail or form pattern or when many views share behaviour through mixins. Both satisfy the same request-in, response-out contract.

Django's path() needs a callable that takes a request and returns a response. MyView.as_view() returns such a function; on every request it builds a fresh MyView instance, calls setup(), then dispatch(), which runs the handler named after the HTTP method.

Set model = Property. ListView renders listings/property_list.html with object_list and property_list; DetailView needs a pk or slug from the URL and renders listings/property_detail.html with object and property.

Wrap the ordered QuerySet in Paginator(queryset, per_page), fetch the requested page with get_page(request.GET.get('page')), and pass that Page to the template, which loops over it and uses has_next() and next_page_number() for links.

Route to TemplateView.as_view(template_name="about.html"); it renders that template on GET. Add fixed values with extra_context, or subclass and override get_context_data(), calling super() first so URL kwargs, view and extra_context stay in the context.

Set queryset for a filter fixed at import time; override get_queryset() when it depends on the request, user or URL. The class-level QuerySet is safe because the generic get_queryset() hands each request a copy via .all().

Django's template engine HTML-escapes every variable's output by default, converting < > ' " and & to entities, after filters run and unless the value is already marked safe, so user text like a product review renders as text, not markup.

DIRS lists project template directories searched first, in order; APP_DIRS=True adds each installed app's templates/ subdirectory, searched in INSTALLED_APPS order. Django uses the first file that matches and raises TemplateDoesNotExist if none does.

A filter follows a pipe inside {{ }} and transforms the value before output. Filters chain left to right, each receiving the previous result, and each takes at most one argument after a colon: a literal, a number or a variable.

A child template starts with {% extends 'base.html' %}; each {% block %} it defines replaces the same-named block in the parent, blocks it skips keep the parent's default, and {{ block.super }} inserts the parent block's content instead of discarding it.

{% for item in items %} repeats its body per element; an {% empty %} clause renders instead when the sequence is empty or missing. Inside, forloop exposes counter, counter0, revcounter, revcounter0, first, last, length and parentloop.

A Django form is bound when it is built with data= or files= (even an empty dict) and unbound otherwise. Only a bound form validates; cleaned_data appears once is_valid() or errors runs full_clean() on it.

A Django ModelForm generates a form field for each selected editable model field, mapping type, max_length, blank, choices, labels and help text, and its save() writes the instance. Meta must name fields or exclude, or class creation raises ImproperlyConfigured.

Since Django 5.0, {{ form }} renders django/forms/div.html: top-level errors, then one <div> per visible field holding its label, help text, errors and widget. By hand, use each BoundField's label_tag, help_text, errors and the field itself.

A Django Field coerces and validates input into a Python value; its Widget renders the HTML and extracts the raw value. For a native picker use DateInput(attrs={'type': 'date'}, format='%Y-%m-%d'), because browsers accept only ISO dates.

Bind a ModelForm for the order and an inline formset with instance=order to request.POST, validate both, save the order, set formset.instance to it and call formset.save(), which stamps each new line with the order's key.

null=True lets the database column store NULL; blank=True lets validation (forms and full_clean) accept an empty value. On CharField and TextField, Django's convention is blank=True with an empty string, so there is one 'no data' value, not two.

Django adds an auto-incrementing id field. Its class comes from the app's AppConfig.default_auto_field if set, otherwise from the DEFAULT_AUTO_FIELD setting, which defaults to BigAutoField since Django 6.0 (AutoField before).

class Meta holds model-level options rather than fields: the table name (db_table), default ordering, human-readable names, indexes, constraints and a few behaviour switches. Django reads it when building the model's _meta; it never becomes a column.

on_delete tells Django what to do with rows that reference an object when that object is deleted: delete them too (CASCADE), refuse the delete (PROTECT, RESTRICT), or rewrite their key (SET_NULL, SET_DEFAULT, SET()). It is required on every ForeignKey and OneToOneField.

TextChoices and IntegerChoices are enums whose members carry a stored value and a human label; pass the class as choices=. Choices are enforced by model validation and forms only, so save(), update() or raw SQL can still store any value.

aggregate() computes summary values over the whole QuerySet and immediately returns a dict. annotate() adds a computed value to every object and returns a new, lazy QuerySet you can keep filtering and ordering.

Building or chaining a QuerySet only composes a query and returns a new QuerySet. SQL runs when Python needs rows: iteration, list(), len(), bool() or an if test, repr(), a slice with a step, or pickling.

filter() returns a lazy QuerySet of zero or more rows and never raises for no matches. get() runs immediately and returns exactly one instance, raising Model.DoesNotExist for none and Model.MultipleObjectsReturned for more than one.

Manager.raw() runs a SELECT and returns a lazy RawQuerySet of model instances, matched to fields by column name, so the primary key must be selected. connection.cursor() bypasses models: it runs any statement and returns plain tuples.

Each QuerySet caches its own rows after its first full evaluation, but helpers, .all(), filter() and template lookups like user.orders.all build new QuerySets with empty caches. Evaluate one QuerySet once and reuse that object everywhere.

update() with F() sends one UPDATE that adds 50 to the stored value inside the database: one round trip, no lost updates. The save() loop runs a SELECT plus an UPDATE per customer and can overwrite concurrent changes.

values() yields dictionaries keyed by field name and values_list() yields tuples, both skipping model instances. flat=True with one field returns bare values; named=True returns namedtuples called Row.

By default Django loads a ForeignKey's target only when it is first read, so each order.customer access in the loop runs its own SELECT. select_related('customer') joins the customer table into the list query, so every customer arrives with its order.

str(queryset.query) previews the SELECT one QuerySet would run, with parameters crudely pasted in; django.db.connection.queries logs every statement actually executed on that connection, with timings, but only while DEBUG is True.

defer() leaves named columns out of the SELECT and only() loads just the named ones; you still get model instances. Reading a skipped field later runs one extra query for that instance under the default FETCH_ONE mode.

Django runs in autocommit, so every ORM query commits on its own. transaction.atomic, used as a decorator or a with-block, runs its queries in one transaction: committed if the block exits normally, rolled back if an exception escapes it.

DATABASES maps aliases such as default to connection settings: ENGINE picks the backend, NAME the database, plus USER, PASSWORD, HOST, PORT and OPTIONS. Moving to PostgreSQL means installing psycopg, setting ENGINE to django.db.backends.postgresql with credentials, and running migrate.

transaction.on_commit() registers a callable to run after the current transaction commits and drops it if the transaction rolls back. Sending the receipt from it means no customer is emailed about an order that was never saved.

select_for_update() makes the query lock the rows it returns until the transaction ends, so a second buyer's read waits until the first commits. Outside atomic, autocommit would release the lock at once, so Django raises TransactionManagementError.

The ORM hides SQL syntax, not engine behaviour: SQLite matches strings differently, stores decimals as floats, ignores select_for_update(), rebuilds tables for schema changes and serialises writers, so code tested only on SQLite can fail or change results on PostgreSQL or MySQL.

makemigrations writes migration files describing model changes; migrate runs unapplied migration files against a database. Each applied migration is recorded as an (app, name, applied) row in that database's django_migrations table.

Both 0042 files depend on 0041, so the orders app's migration graph ends in two leaf nodes and Django refuses to guess their order. Run makemigrations --merge to add a migration depending on both, after checking they touch different fields.

dumpdata writes database rows out as a fixture (JSON by default; XML, JSONL or YAML on request) and loaddata reads fixtures back in one transaction, searching each installed app's fixtures directory, then FIXTURE_DIRS, then the current directory.

Create an empty migration with makemigrations --empty, write a function taking (apps, schema_editor) that loads the model via apps.get_model and fills the new columns, and add it to operations as migrations.RunPython, ideally with a reverse function.

apps.get_model() returns the historical model rebuilt from the migrations up to that point; an imported model is today's class, so replaying old migrations on a fresh database breaks once its fields no longer match that step's schema.

Register a model in the app's admin.py with admin.site.register(Ticket, TicketAdmin) or the @admin.register(Ticket) decorator on a ModelAdmin subclass. The change list shows the columns named in ModelAdmin.list_display, defaulting to the object's str.

is_staff lets an active user into the Django admin; is_superuser makes has_perm() return True for every permission. They are independent: a superuser with is_staff=False cannot log in to the admin, and a staff user with no permissions sees nothing to edit.

Pass permissions=["ship"] to @admin.action and define has_ship_permission(self, request) on the ModelAdmin. The admin hides the action from users failing every listed check and refuses a forged POST for it; per-object checks remain your job.

Write a function taking (modeladmin, request, queryset), decorate it with @admin.action(description=...), and list it in the ModelAdmin's actions. The queryset holds the ticked rows; returning None sends the user back to the change list.

Define a TabularInline or StackedInline subclass with model = Lesson and list it in the course ModelAdmin's inlines. Tabular renders one compact row per lesson, stacked renders each lesson as a full form; the only difference is the template.

authenticate() checks credentials against the configured backends and returns a user or None without changing any state. login() takes that user and records it in the session, so later requests arrive with request.user set. A sign-in view needs both steps.

Decorate a function view with @login_required or put LoginRequiredMixin first in a class-based view's bases. An anonymous request is redirected to settings.LOGIN_URL (default /accounts/login/) with ?next= carrying the original path.

Subclass AbstractUser to keep the full default user and add fields. Use AbstractBaseUser when the identity shape differs: it supplies only password and last_login, so you define the fields, USERNAME_FIELD and a manager, adding PermissionsMixin for groups.

authenticate() tries each backend in AUTHENTICATION_BACKENDS order and returns the first user found. Returning None passes to the next backend; raising PermissionDenied stops the chain, so authenticate() returns None without trying later backends.

Subclass ModelBackend, override authenticate() to look the user up by email case-insensitively, check_password() it, return the user only if user_can_authenticate() passes, and add the class to AUTHENTICATION_BACKENDS. get_user() and permissions are inherited.

Decorate the view with permission_required("app_label.codename") from django.contrib.auth.decorators. Any user lacking it, logged in or not, is redirected to LOGIN_URL with a next parameter; raise_exception=True raises PermissionDenied and yields a 403 instead.

Django creates add, change, delete and view permissions for every model when migrate runs. You check one with user.has_perm('app_label.codename'), for example has_perm('newsroom.change_article'), where the codename is the action plus the lowercase model name.

A Group holds a set of permissions, and every user in user.groups inherits them. ModelBackend takes the union of the group permissions and the direct user.user_permissions, so a permission from either source grants access and nothing can subtract one.

PermissionRequiredMixin checks request.user.has_perms() in dispatch(), before get() or post(). On failure handle_no_permission() raises PermissionDenied (403) for logged-in users and redirects anonymous ones to login unless raise_exception is True; override has_permission() or handle_no_permission() to customise.

Fetch the listing through a queryset limited to the user, such as get_object_or_404(Listing, pk=pk, owner=request.user), so another owner's listing returns 404. Apply the same scoping to list, update and delete views, and never rely on change_listing alone.

Security, Session, Common, Csrf, Authentication, Messages, XFrameOptions. AuthenticationMiddleware reads the logged-in user's id from request.session, which SessionMiddleware attaches; listed first, it raises ImproperlyConfigured. The default message storage needs the session too.

Write a factory that receives get_response: a class whose init(self, get_response) runs once at startup and whose call(self, request) runs per request, calling get_response and returning the response. Register its dotted path in MIDDLEWARE.

Declare a Django middleware hybrid with sync_and_async_middleware (or both class flags True), check inspect.iscoroutinefunction(get_response) once in the factory, and return an async def callable for async stacks and a plain function for sync ones.

They declare which request modes a Django middleware factory can handle: sync_capable defaults to True and async_capable to False, so an undecorated middleware is sync-only and Django adapts it with a thread hop under ASGI.

GZipMiddleware goes above anything that reads or changes the response body, so it compresses the final bytes. LocaleMiddleware goes after SessionMiddleware and before CommonMiddleware. CommonMiddleware stays near the top; middleware above it that changes the body must reset Content-Length.

Django saves request.session only when it is marked modified, and only assignments or deletions on the session itself set that flag. Mutating a nested list does not, so reassign the key or set request.session.modified = True.

Call messages.success(request, 'Profile saved.') from django.contrib.messages before returning the redirect, and loop over messages in the base template; MessageMiddleware stores the notice across the redirect and iteration clears it.

Signer.sign() appends an HMAC-SHA256 signature derived from SECRET_KEY, so unsign() detects any change and raises BadSignature. It does not encrypt: the value, or its base64 JSON, travels in the clear.

Django's SESSION_ENGINE selects db (the default, a django_session table), cache, cached_db (database with a write-through cache), file, or signed_cookies (data in a signed cookie); they differ in durability, speed, fleet-sharing and revocability.

Sign the subscriber id with signing.dumps(..., salt=...), which embeds a signed timestamp. The view calls signing.loads(token, salt=..., max_age=timedelta(days=30)), catching SignatureExpired before BadSignature.

Add django.middleware.csp.ContentSecurityPolicyMiddleware to MIDDLEWARE and fill SECURE_CSP (enforced header) and/or SECURE_CSP_REPORT_ONLY (report-only header) with directive dictionaries. Both default to {}, which sends no header.

{% csrf_token %} renders a hidden csrfmiddlewaretoken input carrying a masked copy of the visitor's CSRF secret. CsrfViewMiddleware answers 403 Forbidden to a POST whose token is missing or does not match the csrftoken cookie.

ALLOWED_HOSTS lists the domain names a Django site may serve; request.get_host() rejects any other Host with DisallowedHost, a 400. An empty list is only tolerated for localhost while DEBUG=True, so switching DEBUG off without filling it breaks every request.

Read the token from the csrftoken cookie, or from a rendered csrfmiddlewaretoken input, and send it in an X-CSRFToken request header. Django reads the token only from form-encoded POST data or that header, never from a JSON body.

The balancer talks plain HTTP to Django, so request.is_secure() is False and SecurityMiddleware redirects HTTPS users again forever. Set SECURE_PROXY_SSL_HEADER to the header the balancer sets, or redirect at the balancer instead.

STATIC_URL is the URL prefix static files are served under; STATIC_ROOT is the one directory collectstatic copies into; STATICFILES_DIRS lists extra project-wide source directories. {% static %} gets each URL from the staticfiles storage instead of hard-coding it.

MEDIA_ROOT is the filesystem directory where Django's default FileSystemStorage writes uploads; MEDIA_URL is the public URL prefix for them. A FileField stores only the file's name relative to the storage root, and .url asks the storage to build the link.

Install WhiteNoise, add WhiteNoiseMiddleware right after SecurityMiddleware, set STATIC_ROOT and STORAGES['staticfiles'] to CompressedManifestStaticFilesStorage, and run collectstatic while building the image so the files exist before the app starts.

With DEBUG on, staticfiles' runserver serves files straight from the finders. With DEBUG off that handler is not installed and nothing serves STATIC_URL, so run collectstatic and serve STATIC_ROOT from a web server, CDN or static-serving middleware.

ManifestStaticFilesStorage saves, during collectstatic, a copy of each static file named with a 12-character MD5 content hash and records original-to-hashed names in staticfiles.json; {% static %} resolves through that map, so a changed file gets a new URL.

Django's cache.set(key, value, timeout) stores a picklable value, cache.get(key, default) returns it or the default on a miss, and cache.add() stores only if the key is absent. timeout=None means never expire; timeout=0 means do not cache.

Django's cache_page stores a view's whole GET or HEAD response in the cache and serves it for later requests to the same URL. timeout is the lifetime in seconds, cache picks the CACHES alias, and key_prefix namespaces the keys.

Pick a shared network backend, RedisCache or PyMemcacheCache, so all three servers and every worker read the same forecasts. DatabaseCache works when no cache server is allowed; LocMemCache, FileBasedCache and DummyCache do not share across servers.

LocMemCache keeps entries in a Python dict inside each process. With several worker processes every worker has its own private copy, so a set or delete in one worker is invisible to the others and readers see stale or missing values.

Django's {% cache timeout name var1 var2 %} stores the rendered block under a key from the fragment name and the extra arguments' string values. To invalidate, rebuild it with make_template_fragment_key(name, [vars]) and delete it from the same alias.

QuerySet builders such as filter(), exclude() and order_by() run no SQL, so they stay unchanged. Calls that execute a query use awaited a-prefixed versions: aget(), afirst(), acount(), acreate(). Iterate with async for.

Declare a function-based view with async def. For a class-based view, declare its HTTP handlers such as get() and post() with async def, leaving as_view() alone; the handlers must be all async or all sync.

sync_to_async wraps a sync function so async code can await it, running it on a worker thread. async_to_sync wraps a coroutine function so sync code can call it and block for the result. Django uses both internally.

Under both, asyncio.gather overlaps the three calls, so that request takes roughly as long as the slowest one. Only under ASGI does the process serve other requests while it awaits; under WSGI it holds a worker for the whole request.

Django guards its database layer as async-unsafe: when a guarded call runs in a thread with a running event loop, it raises SynchronousOnlyOperation. Use the async ORM API or wrap the sync code in sync_to_async; never DJANGO_ALLOW_ASYNC_UNSAFE.

Create proj/celery.py that sets DJANGO_SETTINGS_MODULE, builds Celery('proj'), calls config_from_object('django.conf:settings', namespace='CELERY') and autodiscover_tasks(); then import that app in proj/init.py so it loads whenever Django starts.

send_mail() sends one message, optionally with an html_message alternative, to a recipient list that all appear in To. For CC, BCC, Reply-To, custom headers or attachments, build an EmailMessage, or an EmailMultiAlternatives to add body versions.

Connect a receiver to post_save with sender=settings.AUTH_USER_MODEL and create the Profile only when the created argument is True, so later saves of the same user do not insert a second profile.

QuerySet.update(), bulk_create() and bulk_update() write SQL directly and send no pre_save or post_save; raw SQL sends nothing; DB_CASCADE deletes (Django 6.1) send no delete signals. QuerySet.delete() still sends pre_delete and post_delete per object.

The task is queued before the transaction commits, so the worker's separate connection may not see the order yet. Queue it with transaction.on_commit(), or Celery's delay_on_commit() on Django projects, so the message is sent only after commit.

In Python, wrap the string in gettext(), usually imported as _. In a template, add {% load i18n %}, then use {% translate %} for a constant string or {% blocktranslate %} for a sentence with variables. Use named placeholders, never f-strings.

With USE_TZ on, timezone.now() returns an aware datetime in UTC, matching how Django stores datetimes. datetime.now() is naive local time: saving it makes Django warn and assume TIME_ZONE, and comparing it with aware values raises TypeError.

makemessages scans source files for marked strings and creates or updates a human-editable .po file per language. compilemessages turns each .po into the binary .mo file that Django actually loads at runtime. Translators edit .po; Django reads only .mo.

LocaleMiddleware tries the URL language prefix (only under i18n_patterns), then the django_language cookie, then the Accept-Language header by q-value, and finally LANGUAGE_CODE. Each candidate must match a language in LANGUAGES.

Model and form fields are class attributes, evaluated once when the module is imported, before any request activates a language. gettext() would translate at that moment. gettext_lazy() returns a proxy that translates whenever it is rendered, in the language active for that request.

With DEBUG = True Django returns its technical 500 page: traceback, local variables, request data and most settings. With DEBUG = False the visitor gets the 500.html template, and the details go to logging and ADMINS emails.

Django runs dictConfig(DEFAULT_LOGGING), then your LOGGING as a second pass. With disable_existing_loggers True, the dictConfig default, loggers you don't name, including django.request, are disabled and silently drop 500-error records and admin emails.

Read the Timer panel to see whether time is CPU or waiting, then the SQL panel's count, slow queries and similar or duplicated groups, whose stack traces point at the triggering line. Templates, Cache and Signals panels explain the rest.

DEFAULT_LOGGING sends the django logger's INFO and above to the console when DEBUG is True. When DEBUG is False, only ERROR and above leave, emailed to ADMINS by AdminEmailHandler; everything else is dropped. runserver's django.server lines always print.

Add debug_toolbar to INSTALLED_APPS, its URLs via debug_toolbar_urls(), DebugToolbarMiddleware early in MIDDLEWARE, and 127.0.0.1 to INTERNAL_IPS. It stays hidden if DEBUG is False, your IP is not internal, or the response is not HTML with a </body>.

SimpleTestCase forbids database queries. TransactionTestCase lets code commit and then truncates every table after each test. TestCase wraps each test in a transaction rolled back at the end, which is much faster, so most database tests use TestCase.

Django's test Client runs a request through URL routing, every middleware and template rendering, like an in-process browser. RequestFactory only builds a request object you pass to one view yourself, with no middleware, so you set request.user and session by hand.

Django's test runner creates a separate database named 'test_' plus each NAME in DATABASES (in memory for SQLite), runs migrate into it, runs the tests, and destroys it at the end unless --keepdb is passed.

Django's test runner swaps in the locmem email backend, which appends every sent message to django.core.mail.outbox. Post to the view under @override_settings(DEFAULT_FROM_EMAIL=...), then assert len(mail.outbox) == 1 and inspect that message.

pytest-django blocks database access unless a test opts in, so an unmarked query raises RuntimeError. Add @pytest.mark.django_db or request the db fixture; the test then runs in a transaction that is rolled back afterwards.

DEBUG=True shows tracebacks with local variables, request data and most settings to anyone who triggers an error, and keeps a SQL log in memory. Turning it off requires a real ALLOWED_HOSTS, another way to serve static files, and 404/500 templates.

runserver is a development server: it auto-reloads, runs in one process and was never security-audited or performance-tested. Production runs the project's wsgi.py or asgi.py application object under a real WSGI or ASGI server, usually behind a reverse proxy.

collectstatic reads files already in the code and writes them to STATIC_ROOT, so its output belongs in the immutable image. migrate alters the shared database, so it runs once per release, before new-code containers serve requests.

Each file sets a default DJANGO_SETTINGS_MODULE with os.environ.setdefault and builds a module-level application via get_wsgi_application() or get_asgi_application(). A value already in the environment wins, so each deployment picks its settings without editing the file.

Pass --noinput (or --no-input) so no command waits for a prompt, give createsuperuser its values through options or DJANGO_SUPERUSER_* environment variables, and rely on the exit status: a failing command exits non-zero and fails the step.