Фреймворк проверки системы

Фреймворк системной проверки - это набор статических проверок для проверки проектов Django. Он обнаруживает типичные проблемы и дает советы по их устранению. Фреймворк является расширяемым, поэтому вы можете легко добавлять свои собственные проверки.

Проверки можно запускать явно с помощью checkкоманды. Проверки запускаются неявно перед большинством команд, включая runserverи migrate. По соображениям производительности проверки не выполняются как часть стека WSGI, используемого при развертывании. Если вам нужно запустить системные проверки на сервере развертывания, активируйте их явно с помощью check.

Серьезные ошибки runserverвообще не позволят запускать команды Django (например, ). О незначительных проблемах сообщается на консоль. Если вы выяснили причину предупреждения и готовы ее проигнорировать, вы можете скрыть определенные предупреждения, используя SILENCED_SYSTEM_CHECKSпараметр в файле настроек проекта.

Полный список всех проверок, которые может выполнять Django, можно найти в справочнике по проверкам системы .

Написание собственных чеков

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

from django.core.checks import Error, register

@register()
def example_check(app_configs, **kwargs):
    errors = []
    # ... your check logic here
    if check_failed:
        errors.append(
            Error(
                'an error',
                hint='A hint.',
                obj=checked_object,
                id='myapp.E001',
            )
        )
    return errors

Функция проверки должна принимать app_configsаргумент; этот аргумент - список приложений, которые следует проверить. Если None, то проверка должна выполняться для всех установленных приложений в проекте. **kwargsАргумент необходим для расширения в будущем.

Сообщения

Функция должна возвращать список сообщений. Если в результате проверки проблем не обнаружено, функция проверки должна вернуть пустой список.

Предупреждения и ошибки, вызванные методом проверки, должны быть экземплярами CheckMessage. Экземпляр CheckMessageинкапсулирует одну сообщаемую ошибку или предупреждение. Он также предоставляет контекст и подсказки, применимые к сообщению, и уникальный идентификатор, который используется для целей фильтрации.

Эта концепция очень похожа на сообщения из инфраструктуры сообщений или среды ведения журналов . Сообщения помечаются значком, levelуказывающим на серьезность сообщения.

Существуют также ярлыки, упрощающие создание сообщений с общими уровнями. При использовании этих классов вы можете опустить levelаргумент, потому что он подразумевается именем класса.

Регистрация и маркировка чеков

Наконец, ваша функция проверки должна быть явно зарегистрирована в системном реестре проверки. Проверки должны быть зарегистрированы в файле, который загружается при загрузке вашего приложения; например, в AppConfig.ready()методе.

register( * теги) (функция )

Вы можете передать любое количество тегов register, чтобы пометить свой чек. Пометка проверок полезна, поскольку позволяет запускать только определенную группу проверок. Например, чтобы зарегистрировать проверку совместимости, вы должны сделать следующий вызов:

from django.core.checks import register, Tags

@register(Tags.compatibility)
def my_check(app_configs, **kwargs):
    # ... perform compatibility checks and collect errors
    return errors

Вы можете зарегистрировать «проверки развертывания», которые относятся только к производственному файлу настроек, например:

@register(Tags.security, deploy=True)
def my_check(app_configs, **kwargs):
    ...

Эти проверки будут запускаться только при использовании этой опции.check --deploy

Вы также можете использовать registerкак функцию, а не декоратор, передав вызываемый объект (обычно функцию) в качестве первого аргумента register.

Приведенный ниже код эквивалентен приведенному выше коду:

def my_check(app_configs, **kwargs):
    ...
register(my_check, Tags.security, deploy=True)

Проверка поля, модели, менеджера и базы данных

В некоторых случаях вам не нужно регистрировать функцию проверки - вы можете использовать уже существующую регистрацию.

Поля, модели, менеджеры моделей и серверные части базы данных - все реализуют check()метод, который уже зарегистрирован в структуре проверки. Если вы хотите добавить дополнительные проверки, вы можете расширить реализацию базового класса, выполнить любые дополнительные проверки, которые вам нужны, и добавить любые сообщения к сообщениям, сгенерированным базовым классом. Рекомендуется делегировать каждую проверку отдельным методам.

Рассмотрим пример, в котором вы реализуете настраиваемое поле с именем RangedIntegerField. Это поле добавляет minи maxаргументы конструктору IntegerField. Вы можете добавить проверку, чтобы гарантировать, что пользователи предоставляют минимальное значение, которое меньше или равно максимальному значению. Следующий фрагмент кода показывает, как можно реализовать эту проверку:

from django.core import checks
from django.db import models

class RangedIntegerField(models.IntegerField):
    def __init__(self, min=None, max=None, **kwargs):
        super().__init__(**kwargs)
        self.min = min
        self.max = max

    def check(self, **kwargs):
        # Call the superclass
        errors = super().check(**kwargs)

        # Do some custom checks and add messages to `errors`:
        errors.extend(self._check_min_max_values(**kwargs))

        # Return all errors and warnings
        return errors

    def _check_min_max_values(self, **kwargs):
        if (self.min is not None and
                self.max is not None and
                self.min > self.max):
            return [
                checks.Error(
                    'min greater than max.',
                    hint='Decrease min or increase max.',
                    obj=self,
                    id='myapp.E001',
                )
            ]
        # When no error, return an empty list
        return []

Если вы хотите добавить проверки в диспетчер моделей, вы примените тот же подход к своему подклассу Manager.

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

class MyModel(models.Model):
    @classmethod
    def check(cls, **kwargs):
        errors = super().check(**kwargs)
        # ... your own checks ...
        return errors

Написание тестов

Сообщения сопоставимы. Это позволяет легко писать тесты:

from django.core.checks import Error
errors = checked_object.check()
expected_errors = [
    Error(
        'an error',
        hint='A hint.',
        obj=checked_object,
        id='myapp.E001',
    )
]
self.assertEqual(errors, expected_errors)

Copyright ©2021 All rights reserved