系统检查框架
- Writing your own checks

系统检查框架

系统检查框架是一组验证Django项目的静态检查。它检测到常见的问题，并提供了如何解决这些问题的提示。该框架是可扩展的，所以你可以轻松地添加自己的检查。

Checks can be triggered explicitly via the check command. Checks aretriggered implicitly before most commands, including runserver andmigrate. For performance reasons, checks are not run as part of theWSGI stack that is used in deployment. If you need to run system checks on yourdeployment server, trigger them explicitly using check.

Serious errors will prevent Django commands (such as runserver) fromrunning at all. Minor problems are reported to the console. If you have inspectedthe cause of a warning and are happy to ignore it, you can hide specific warningsusing the SILENCED_SYSTEM_CHECKS setting in your project settings file.

A full list of all checks that can be raised by Django can be found in theSystem check reference.

Writing your own checks

The framework is flexible and allows you to write functions that performany other kind of check you may require. The following is an example stubcheck function:

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

The check function must accept an appconfigs argument; this argument isthe list of applications that should be inspected. If None, the check must berun on _all installed apps in the project. The **kwargs argument is requiredfor future expansion.

消息

The function must return a list of messages. If no problems are found as a resultof the check, the check function must return an empty list.

The warnings and errors raised by the check method must be instances ofCheckMessage. An instance ofCheckMessage encapsulates a single reportableerror or warning. It also provides context and hints applicable to themessage, and a unique identifier that is used for filtering purposes.

The concept is very similar to messages from the message framework or the logging framework.Messages are tagged with a level indicating the severity of the message.

There are also shortcuts to make creating messages with common levels easier.When using these classes you can omit the level argument because it isimplied by the class name.

Registering and labeling checks

Lastly, your check function must be registered explicitly with system checkregistry. Checks should be registered in a file that's loaded when yourapplication is loaded; for example, in the AppConfig.ready() method.

register(*tags)(function)
You can pass as many tags to register as you want in order to label yourcheck. Tagging checks is useful since it allows you to run only a certaingroup of checks. For example, to register a compatibility check, you wouldmake the following call:

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

You can register "deployment checks" that are only relevant to a productionsettings file like this:

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

These checks will only be run if the check —deploy option is used.

You can also use register as a function rather than a decorator bypassing a callable object (usually a function) as the first argumentto register.

The code below is equivalent to the code above:

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

Field, model, manager, and database checks

In some cases, you won't need to register your check function — you canpiggyback on an existing registration.

Fields, models, model managers, and database backends all implement acheck() method that is already registered with the check framework. If youwant to add extra checks, you can extend the implementation on the base class,perform any extra checks you need, and append any messages to those generatedby the base class. It's recommended that you delegate each check to separatemethods.

Consider an example where you are implementing a custom field namedRangedIntegerField. This field adds min and max arguments to theconstructor of IntegerField. You may want to add a check to ensure that usersprovide a min value that is less than or equal to the max value. The followingcode snippet shows how you can implement this check:

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 []

If you wanted to add checks to a model manager, you would take the sameapproach on your subclass of Manager.

If you want to add a check to a model class, the approach is almost the same:the only difference is that the check is a classmethod, not an instance method:

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

Writing tests

Messages are comparable. That allows you to easily write tests:

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)