Выбор полей (сhoices) Django в действительности не ограничивает ваши данные

Перевод: Adam Johnson – Django’s Field Choices Don’t Constrain Your Data

Этот статья описывает несколько не очевидный способ работы Field.choices в Django.

Возьмем для примера определение модели Django:

from django.db import models

class Status(models.TextChoices):
    UNPUBLISHED = 'UN', 'Unpublished'
    PUBLISHED = 'PB', 'Published'


class Book(models.Model):
    status = models.CharField(
        max_length=2,
        choices=Status.choices,
        default=Status.UNPUBLISHED,
    )

    def __str__(self):
        return f"{self.id} - {Status(self.status).label}"

Если мы откроем shell, мы можем легко создать Book с заданным выбором status:

$ python manage.py shell  # with ipython installed
...
In [1]: from core.models import Status, Book

In [2]: Book.objects.create(status=Status.UNPUBLISHED)
Out[2]: <Book: 1 - Unpublished>

Список вариантов (choices) ограничивает значение status во время проверки модели (model validation) в Python:

In [3]: book = Book.objects.get(id=1)

In [4]: book.status = 'republished'

In [5]: book.full_clean()
---------------------------------------------------------------------------
ValidationError                           Traceback (most recent call last)
<ipython-input-7-e64237e0a92a> in <module>
----> 1 book.full_clean()

.../django/db/models/base.py in full_clean(self, exclude, validate_unique)
   1220
   1221         if errors:
-> 1222             raise ValidationError(errors)
   1223
   1224     def clean_fields(self, exclude=None):

ValidationError: {'status': ["Value 'republished' is not a valid choice."]}

И это отлично подходит для ModelForms и других случаев с использованием проверки. Пользователи не могут выбирать неправильные варианты и получать сообщения об ошибки если попробуют записать неверные данные.

К сожалению, нам, как разработчикам, по-прежнему легко записать эти недопустимые данные в базу данных:

In [6]: book.save()

Опс!

Также возможно обновить все наши экземпляры до недопустимого значения status через однострочную команду:

In [8]: Book.objects.update(status='republished')
Out[8]: 1

Итак, что происходит? Почему Django позволяет нам объявлять набор вариантов, которые мы хотим, чтобы поле принимало, а затем позволяет нам легко обойти это?

Что ж, проверка модели в Django предназначена в основном для форм. Он полагается, что другой код в вашем приложении «знают, что делает».

Если мы хотим предотвратить это, самое общее решение – заставить саму базу данных отклонять неверные данные. Это не только сделает ваш код Django более надежным, но и любые другие приложения, использующие базу данных, также будут использовать ограничения.

Мы можем добавить такие ограничения с помощью класса CheckConstraint, добавленного в Django 2.2. Для нашей модели нам нужно определить и назвать единственный фильтр CheckConstraint в Meta.constraints:

class Book(models.Model):
    status = models.CharField(
        max_length=2,
        choices=Status.choices,
        default=Status.UNPUBLISHED,
    )

    def __str__(self):
        return f"{self.id} - {Status(self.status).label}"

    class Meta:
        constraints = [
            models.CheckConstraint(
                name="%(app_label)s_%(class)s_status_valid",
                check=models.Q(status__in=Status.values),
            )
        ]

Объект Q представляет собой одно выражение, которое мы передаем в Model.objects.filter (). Ограничения могут иметь любое количество логики для полей в текущей модели. Это включает в себя все виды поиска, сравнения между полями и функции базы данных.

Запустив makemigrations, мы получим миграцию, которая выглядит так:

from django.db import migrations, models


class Migration(migrations.Migration):

    dependencies = [
        ("core", "0001_initial"),
    ]

    operations = [
        migrations.AddConstraint(
            model_name="book",
            constraint=models.CheckConstraint(
                check=models.Q(status__in=["UN", "PB"]),
                name="%(app_label)s_%(class)s_status_valid",
            ),
        ),
    ]

Если мы попытаемся применить ее, пока база данных содержит недопустимые данные, то мы получим ошибку:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: core
Running migrations:
  Applying core.0002_book_status_valid...Traceback (most recent call last):
...
  File "/.../django/db/backends/sqlite3/base.py", line 396, in execute
    return Database.Cursor.execute(self, query, params)
django.db.utils.IntegrityError: CHECK constraint failed: status_valid

Если мы очистим эти данные вручную и попробуем снова, они пройдут:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: core
Running migrations:
  Applying core.0002_book_status_valid... OK

С этого момента база данных не позволит нам вставлять недопустимые строки или обновлять допустимые строки, чтобы они были недопустимыми:

In [4]: book.save()
---------------------------------------------------------------------------
...
/.../django/db/backends/sqlite3/base.py in execute(self, query, params)
    394             return Database.Cursor.execute(self, query)
    395         query = self.convert_query(query)
--> 396         return Database.Cursor.execute(self, query, params)
    397
    398     def executemany(self, query, param_list):

IntegrityError: CHECK constraint failed: status_valid

In [5]: Book.objects.update(status='republished')
---------------------------------------------------------------------------
...
/.../django/db/backends/sqlite3/base.py in execute(self, query, params)
    394             return Database.Cursor.execute(self, query)
    395         query = self.convert_query(query)
--> 396         return Database.Cursor.execute(self, query, params)
    397
    398     def executemany(self, query, param_list):

IntegrityError: CHECK constraint failed: status_valid

Супер!

В настоящее время Django не может отображать ошибки IntegrityErrors для пользователей при проверке модели. Ничто не сможет их уловить и превратить в ValidationErrors, которые могут нести сообщения, обращенные к пользователю. Согласно документации:

В общем случае ограничения не проверяются во время full_clean () и не вызывают ValidationErrors.

Чтобы это исправить, есть open ticket #30581.

В нашем случае, поскольку мы все еще используем choices, это нормально. Проверка сама по себе не позволит пользователям выбирать недопустимые статусы.

Для более сложных ограничений можно продублировать логику в Python с помощью custom validator.