mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-07-24 05:36:15 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Fixed #25174 -- Moved some details of CheckMessage to the reference guide.

Browse source
This commit is contained in:
Tim Graham 2015-07-28 09:31:44 -04:00
parent 70912e137d
commit faa2a0f662
2 changed files with 96 additions and 60 deletions
Download patch file Download diff file Expand all files Collapse all files

60
docs/ref/checks.txt
View file

@ -2,6 +2,8 @@
System check framework
======================
.. currentmodule:: django.core.checks
The system check framework is a set of static checks for validating Django
projects. It detects common problems and provides hints for how to fix them.
The framework is extensible so you can easily add your own checks.
@ -9,6 +11,64 @@ The framework is extensible so you can easily add your own checks.
For details on how to add your own checks and integrate them with Django's
system checks, see the :doc:`System check topic guide </topics/checks>`.
API Reference
=============
``CheckMessage``
-----------------
.. class:: CheckMessage(level, msg, hint, obj=None, id=None)
The warnings and errors raised by system checks must be instances of
``CheckMessage``. An instance encapsulates a single reportable error or
warning. It also provides context and hints applicable to the message, and a
unique identifier that is used for filtering purposes.
Constructor arguments are:
``level``
The severity of the message. Use one of the predefined values: ``DEBUG``,
``INFO``, ``WARNING``, ``ERROR``, ``CRITICAL``. If the level is greater or
equal to ``ERROR``, then Django will prevent management commands from
executing. Messages with level lower than ``ERROR`` (i.e. warnings) are
reported to the console, but can be silenced.
``msg``
A short (less than 80 characters) string describing the problem. The string
should *not* contain newlines.
``hint``
A single-line string providing a hint for fixing the problem. If no hint
can be provided, or the hint is self-evident from the error message, the
hint can be omitted, or a value of ``None`` can be used.
``obj``
Optional. An object providing context for the message (for example, the
model where the problem was discovered). The object should be a model,
field, or manager or any other object that defines ``__str__`` method (on
Python 2 you need to define ``__unicode__`` method). The method is used
while reporting all messages and its result precedes the message.
``id``
Optional string. A unique identifier for the issue. Identifiers should
follow the pattern ``applabel.X001``, where ``X`` is one of the letters
``CEWID``, indicating the message severity (``C`` for criticals, ``E`` for
errors and so). The number can be allocated by the application, but should
be unique within that application.
There are subclasses to make creating messages with common levels easier. When
using them you can omit the ``level`` argument because it is implied by the
class name.
.. class:: Debug(msg, hint, obj=None, id=None)
.. class:: Info(msg, hint, obj=None, id=None)
.. class:: Warning(msg, hint, obj=None, id=None)
.. class:: Error(msg, hint, obj=None, id=None)
.. class:: Critical(msg, hint, obj=None, id=None)
Builtin checks
==============
Builtin tags
------------