In Django, a WikiPage model generates its slug in an overridden save(); which write paths never run that code?

## Where custom save logic lives Overriding `Model.save()` is the standard way to run code whenever an instance is saved. A wiki page is a typical case: the model fills `slug` from `title` so URLs stay readable. ```python from django.db import models from django.utils.text import slugify class WikiPage(models.Model): title = models.CharField(max_length=200) slug = models.SlugField(max_length=220, unique=True) def save(self, **kwargs): if not self.slug: self.slug = slugify(self.title) super().save(**kwargs) ``` The trap is that this code runs **only when `save()` is called on an instance**. Several common write paths never do that. ## Paths that call save() - `page.save()` directly; - `WikiPage.objects.create(...)`, which builds the instance and saves it; - `get_or_create()` and `update_or_create()` when they create or update a row; - `ModelForm.save()` and therefore the admin and generic edit views. ## Paths that skip it | Path | Why it skips `save()` | |---|---| | `QuerySet.update(...)` | one SQL `UPDATE`; no instances are loaded | | `bulk_create([...])` | batches `INSERT` statements without calling each instance's `save()` | | `bulk_update([...], fields)` | batches `UPDATE` statements the same way | | raw SQL / `connection.cursor()` | the ORM is not involved at all | | `loaddata` fixtures | each object is written through `Model.save_base(raw=True)`, bypassing the overridden method | | data migrations (`RunPython`) | historical models are rebuilt from migration state and have no custom methods | Django's docs say it plainly: when creating or updating in bulk, none of `save()`, `pre_save` or `post_save` are called, and there is no workaround. ## The delete side The same applies to `delete()`. `QuerySet.delete()` performs a bulk delete and does not call an overridden `Model.delete()`; neither do cascades triggered by `on_delete`. Deletion signals are still sent in those cases, which is why the docs point to them for delete logic that must always run. Single-instance `page.delete()` does call the override. ## Writing the override correctly 1. **Accept keyword arguments and pass them on**: `def save(self, **kwargs)` and `super().save(**kwargs)`. Django 6.0 removed positional arguments to `save()`, and future keyword arguments keep working when you forward `**kwargs`. 2. **Always call `super().save()`** unless you deliberately block the save; forgetting it means nothing reaches the database. 3. **Add derived fields to `update_fields`** when the caller passed it: if `title` is being saved and you recompute `slug`, include `slug`, or the new slug stays in memory only. 4. **Keep it fast and local**: no network calls, no heavy queries. Every admin save and form submission pays for them. ## How the bypass shows up in production A typical incident: an import command reads a thousand pages from an old system and calls `bulk_create()` for speed. The overridden `save()` never runs, so every row gets the field's empty default for `slug`. Because `slug` is `unique=True`, the first row with an empty slug is inserted and the second collides with it, and the batch fails with an `IntegrityError` for a duplicate key. If `slug` were not unique, the import would succeed and the site would later show a thousand pages whose URLs cannot be reversed. The fix is to compute the slug in the import code (or in a shared helper) before building the objects, and to keep the unique constraint as the safety net that turned a silent data problem into a loud failure. ## Making the rule hold everywhere Once you know which paths skip the override, decide how important the rule is: - **Convenience defaults** (a slug) can live in `save()` plus a shared helper, `WikiPage.build_slug(title)`, that bulk import code calls explicitly before `bulk_create()`. - **Invariants that must never break** (uniqueness, value ranges) belong in the database as constraints, which every writer meets. - **Values the database can compute** can use database defaults or generated columns instead of Python code. - **Data migrations** must copy the logic into the migration, because the historical model cannot call it. An interviewer asking this question wants the list of bypassing paths and the judgment to keep critical rules out of `save()` alone.