Soft delete в Django: реализация и скрытые грабли

Вы добавили в модель поле is_deleted и переопределили delete(), чтобы вместо реального удаления ставить флаг. Через месяц выясняется: сохранить второго пользователя с тем же email нельзя, потому что уникальный индекс считает удалённые записи; отчёт по заказам показывает цифры вдвое больше реальных, потому что аналитик забыл про фильтр; а ForeignKey.on_delete=CASCADE тихо игнорирует вашу «мягкость» и удаляет связанные строки по-настоящему. Разбираем, где soft delete в Django протекает и как эти места закрыть.

Материал написан для Django 4.2 LTS и 5.x. Всё, что ниже, работает на обеих ветках; отдельно отмечены места, где поведение зависит от версии. Инвалидация кеша и права доступа к удалённым записям — отдельные темы, здесь только сам механизм удаления и его последствия для ORM и БД.

Наивная реализация и что с ней не так

Минимальный вариант выглядит так и почти всегда попадает в первый коммит:

# Django 4.2 / 5.x
from django.db import models
from django.utils import timezone


class Article(models.Model):
    title = models.CharField(max_length=200)
    deleted_at = models.DateTimeField(null=True, blank=True, db_index=True)

    def delete(self, using=None, keep_parents=False):
        # Вместо реального удаления проставляем метку времени
        self.deleted_at = timezone.now()
        self.save(update_fields=["deleted_at"])

Проблема даже не в этом коде, а в том, что он покрывает ровно один путь удаления — вызов instance.delete(). А удалить объект в Django можно ещё как минимум двумя способами, и оба пройдут мимо вашего метода:

• Article.objects.filter(...).delete() — QuerySet.delete() не вызывает delete() у каждого объекта, он формирует один SQL DELETE. Ваши записи исчезнут по-настоящему.
• Каскад по ForeignKey с on_delete=CASCADE — когда удаляется родитель, Django удаляет детей на уровне коллектора, минуя переопределённый метод.

Значит, «мягким» надо сделать не только объект, но и менеджер, и QuerySet.

Рабочая реализация: менеджер, QuerySet и базовая модель

Собираем три части: собственный QuerySet с методами мягкого удаления, менеджер, который по умолчанию скрывает удалённое, и абстрактную модель, от которой наследуются нужные сущности.

# Django 4.2 / 5.x
from django.db import models
from django.utils import timezone


class SoftDeleteQuerySet(models.QuerySet):
    def delete(self):
        # Массовое мягкое удаление одним UPDATE
        return super().update(deleted_at=timezone.now())

    def hard_delete(self):
        # Настоящее удаление, когда оно действительно нужно
        return super().delete()

    def alive(self):
        return self.filter(deleted_at__isnull=True)

    def dead(self):
        return self.filter(deleted_at__isnull=False)


class SoftDeleteManager(models.Manager):
    def get_queryset(self):
        # Базовый менеджер отдаёт только живые записи
        return SoftDeleteQuerySet(self.model, using=self._db).alive()


class AllObjectsManager(models.Manager):
    def get_queryset(self):
        return SoftDeleteQuerySet(self.model, using=self._db)


class SoftDeleteModel(models.Model):
    deleted_at = models.DateTimeField(null=True, blank=True, db_index=True)

    objects = SoftDeleteManager()      # только живые
    all_objects = AllObjectsManager()  # живые + удалённые

    class Meta:
        abstract = True

    def delete(self, using=None, keep_parents=False):
        self.deleted_at = timezone.now()
        self.save(update_fields=["deleted_at"])

    def hard_delete(self, using=None, keep_parents=False):
        return super().delete(using=using, keep_parents=keep_parents)

    def restore(self):
        self.deleted_at = None
        self.save(update_fields=["deleted_at"])

Теперь модель наследуется просто:

class Article(SoftDeleteModel):
    title = models.CharField(max_length=200)

Article.objects.all() вернёт только живые записи, Article.all_objects.all() — все. Это ключевое решение: дефолтный менеджер прячет удалённое, а полный доступ живёт под отдельным именем. Обратный вариант (по умолчанию всё, а фильтр вручную) приводит к утечкам удалённых записей в каждый второй запрос.

Главный риск soft delete не в коде удаления, а в том, что о нём забывает каждый, кто пишет запрос через месяц. Поэтому «скрыто по умолчанию» — не удобство, а требование безопасности данных.

Первый менеджер — он же дефолтный

Порядок объявления менеджеров важен. Первый объявленный менеджер становится _default_manager — его использует админка, related-запросы и внутренние механизмы Django. Если сделать первым all_objects, удалённые записи полезут в связанные выборки. Держите objects (скрывающий) первым.

Грабли, которые срабатывают позже

Уникальные индексы считают удалённые записи

Поле unique=True и UniqueConstraint работают на уровне БД и ничего не знают про deleted_at. Удалили пользователя с email="a@b.ru", пытаетесь завести нового с тем же адресом — база возвращает IntegrityError: duplicate key. Решение — частичный уникальный индекс, который учитывает только живые строки. В PostgreSQL это делается через условие в UniqueConstraint (Django 4.2+):

class User(SoftDeleteModel):
    email = models.EmailField()

    class Meta:
        constraints = [
            models.UniqueConstraint(
                fields=["email"],
                condition=models.Q(deleted_at__isnull=True),
                name="uniq_email_alive",
            ),
        ]

Такой индекс есть в PostgreSQL и SQLite (частичные индексы), а вот в MySQL до 8.0 частичные индексы не поддерживаются — там придётся выносить проверку уникальности в приложение или хранить в поле-дискриминаторе. Уберите обычный unique=True с самого поля, иначе оно продолжит блокировать удалённые дубли.

Каскады не станут мягкими сами

on_delete=models.CASCADE реагирует на настоящий DELETE. Если родителя удаляют мягко (через save), каскад вообще не срабатывает — дети остаются живыми и «висят» на удалённом родителе. Если же где-то в коде вызвали hard_delete() или QuerySet.hard_delete(), каскад отработает по-настоящему и снесёт связанные строки без всякой метки. Явного «мягкого каскада» в Django нет. Варианты:

• Мягко удалять детей вручную в переопределённом delete() родителя — надёжно, но многословно.
• Собирать связи через django.db.models.deletion.Collector и проходить их самостоятельно — гибко, но это уже внутренний API, который между версиями меняется, сверяйтесь с исходниками своей версии.
• Оставить детей живыми и фильтровать по живому родителю в запросах — проще всего, если бизнес-логика это допускает.

Сигналы pre_delete / post_delete молчат

При мягком удалении срабатывает save и его сигналы, а pre_delete и post_delete — нет, потому что реального удаления не происходит. Код очистки файлов, инвалидации кеша или записи в аудит, повешенный на post_delete, не выполнится. Если такая логика нужна, вешайте её на переход deleted_at из NULL в дату, отслеживая изменение в save, либо объявите собственный сигнал.

Растущая таблица и запросы

Удалённые строки не исчезают — таблица растёт вечно. На индексируемых полях это терпимо, но полнотабличные операции и VACUUM в PostgreSQL постепенно дорожают. Держите deleted_at под индексом (в примере выше db_index=True уже стоит), а для больших таблиц предусмотрите фоновую задачу физической очистки записей старше N дней через hard_delete().

Когда soft delete не нужен

Если восстановление данных бизнесу не нужно, а на поле есть уникальность — соблазн «на всякий случай пометить» обычно не стоит будущих проблем с индексами. Прежде чем встраивать soft delete в модель, спросите: кто и как часто будет восстанавливать эти записи?

Что проверить перед выкатом

1. Дефолтный менеджер (objects) скрывает удалённое, полный доступ вынесен в all_objects, и objects объявлен первым.
2. Все уникальные поля переведены на частичный UniqueConstraint с условием deleted_at__isnull=True; обычный unique=True снят.
3. Проверено поведение каскадов: что происходит с детьми при мягком и при жёстком удалении родителя.
4. Логика на post_delete перенесена или продублирована на переход deleted_at.
5. Есть план физической очистки старых удалённых строк и мониторинг размера таблицы.

Дальше — посмотрите в проде на долю удалённых строк относительно живых и на время самых частых запросов к таблице с фильтром по deleted_at. Если доля мёртвых записей уходит за половину, а восстанавливают их единицы, пора включать фоновую очистку и переоценивать, нужен ли soft delete вообще для этой модели.