システムチェックフレームワークは、Django プロジェクトを検証するための静的チェックのセットです。一般的な問題を検出し、それらを修正するヒントを提供します。このフレームワークは拡張性があり、独自のチェックを簡単に追加できます。
\nチェックは、check コマンドを介して明示的にトリガーできます。チェックは、runserver や migrate を含むほとんどのコマンドの前に暗黙的にトリガーされます。パフォーマンスのため、チェックはデプロイメントで使用される WSGI スタックの一部としては実行されません。デプロイメントサーバーでシステムチェックを実行する必要がある場合は、 check を使用して明示的にトリガーしてください。
重大なエラーは、Djangoのコマンド (たとえば runserver) の実行を完全に停止します。軽微な問題はコンソールに報告されます。警告の原因を調査し、無視しても問題ない場合は、プロジェクトの設定ファイルである SILENCED_SYSTEM_CHECKS 設定を使用して特定の警告を非表示にできます。
Djangoが発生させる可能性のあるすべてのチェックの完全なリストは、 システムチェックのリファレンス にあります。
\nフレームワークは柔軟で、必要に応じて任意の種類のチェックを実行する関数を書くことができます。以下は、例としてのスタブチェック関数です。
\nfrom django.core.checks import Error, register\n\n\n@register()\ndef example_check(app_configs, **kwargs):\n errors = []\n # ... your check logic here\n if check_failed:\n errors.append(\n Error(\n "an error",\n hint="A hint.",\n obj=checked_object,\n id="myapp.E001",\n )\n )\n return errors\nチェック関数は、 必ず app_configs 引数を受け入れる必要があります。この引数は、調査されるべきアプリケーションのリストです。 None の場合、チェックはプロジェクト内の すべての インストールされたアプリで実行される必要があります。
チェックは databases キーワード引数を受け取ります。これは、データベースレベルの構成を調査するために使用される可能性のあるデータベースエイリアスのリストです。 databases が None の場合、チェックはどのデータベース接続も使用してはいけません。
**kwargs 引数は将来の拡張のために必要です。
関数は、メッセージのリストを返さなければなりません。チェックの結果、問題が見つからない場合、チェック関数は空のリストを返さなければなりません。
\nチェックメソッドで発生させる警告やエラーは、必ず CheckMessage のインスタンスでなければなりません。CheckMessage のインスタンスは、1つの報告可能なエラーや警告をカプセル化します。また、メッセージに適用可能なコンテキストやヒント、フィルタリングの目的で使用される一意の識別子も提供します。
この概念は、 メッセージフレームワーク や ログフレームワーク のメッセージと非常に似ています。メッセージには、メッセージの深刻さを示す「レベル」が付けられます。
\n一般的なレベルのメッセージを簡単に作成するためのショートカットもあります。これらのクラスを使う場合、引数 level はクラス名によって省略できます。
最後に、チェック関数はシステムのチェックレジストリに明示的に登録する必要があります。チェックは、アプリケーションが読み込まれるときに読み込まれるファイル内に登録される必要があります。たとえば、 AppConfig.ready() メソッド内などです。
register には、チェックにラベルを付けるために必要な数のタグを渡すことができます。チェックにタグをつけると、特定のチェックグループだけを実行することができるので便利です。例えば、互換性チェックを登録するには、以下のように呼び出します:
from django.core.checks import register, Tags\n\n\n@register(Tags.compatibility)\ndef my_check(app_configs, **kwargs):\n # ... perform compatibility checks and collect errors\n return errors\n以下のように、本番用の設定ファイルにのみ関係する「デプロイメントチェック」を登録できます:
\n@register(Tags.security, deploy=True)\ndef my_check(app_configs, **kwargs): ...\nこれらのチェックが行われるのは、check --deploy オプションが使用されたときだけです。
また、呼び出し可能オブジェクト（通常は関数）を register の第一引数に渡すことで、デコレータではなく関数として register を使用することもできます。
下記のコードは上記のコードと等価です:
\ndef my_check(app_configs, **kwargs): ...\n\n\nregister(my_check, Tags.security, deploy=True)\n場合によっては、チェック機能を登録する必要はありません。既存の登録に「便乗させる」ことができます。
\nフィールド、モデル、モデルマネージャー、テンプレートエンジン、データベースバックエンドは、すべてチェックフレームワークに登録済みの check() メソッドを実装しています。追加のチェックを行いたい場合は、基底クラスの実装を拡張し、必要な追加チェックを実行して、基底クラスで生成されたメッセージに追記することができます。各チェックを個別のメソッドに委譲することを推奨します。
RangedIntegerField というカスタムフィールドを実装する例を考えてみましょう。このフィールドは IntegerField のコンストラクタに min と max 引数を追加します。ユーザの min 値が max 値以下であることを確認するチェックを追加できます。次のコードスニペットは、このチェックを実装する方法を示しています:
from django.core import checks\nfrom django.db import models\n\n\nclass RangedIntegerField(models.IntegerField):\n def __init__(self, min=None, max=None, **kwargs):\n super().__init__(**kwargs)\n self.min = min\n self.max = max\n\n def check(self, **kwargs):\n # Call the superclass\n errors = super().check(**kwargs)\n\n # Do some custom checks and add messages to `errors`:\n errors.extend(self._check_min_max_values(**kwargs))\n\n # Return all errors and warnings\n return errors\n\n def _check_min_max_values(self, **kwargs):\n if self.min is not None and self.max is not None and self.min > self.max:\n return [\n checks.Error(\n "min greater than max.",\n hint="Decrease min or increase max.",\n obj=self,\n id="myapp.E001",\n )\n ]\n # When no error, return an empty list\n return []\nモデルマネージャにチェックを追加したい場合は、 Manager のサブクラスで同じアプローチを取ります。
モデルクラスにチェックを追加したい場合、アプローチは ほとんど 同じです。唯一の違いは、チェックがインスタンスメソッドではなくクラスメソッドであるということです:
\nclass MyModel(models.Model):\n @classmethod\n def check(cls, **kwargs):\n errors = super().check(**kwargs)\n # ... your own checks ...\n return errors\nメッセージは比較可能なので、次のように簡単にテストを書くことができます。
\nfrom django.core.checks import Error\n\nerrors = checked_object.check()\nexpected_errors = [\n Error(\n "an error",\n hint="A hint.",\n obj=checked_object,\n id="myapp.E001",\n )\n]\nself.assertEqual(errors, expected_errors)\nアプリケーションの読み込み時には特定のチェックを登録する必要があるため、システムチェックフレームワーク内での統合をテストするのが便利です。これは call_command() 関数を使うことで実現できます。
例えば、このテストは SITE_ID の設定が整数でなければならないことを示しています。これは組み込みの サイト フレームワークからのチェック のものです:
from django.core.management import call_command\nfrom django.core.management.base import SystemCheckError\nfrom django.test import SimpleTestCase, modify_settings, override_settings\n\n\nclass SystemCheckIntegrationTest(SimpleTestCase):\n @override_settings(SITE_ID="non_integer")\n @modify_settings(INSTALLED_APPS={"prepend": "django.contrib.sites"})\n def test_non_integer_site_id(self):\n message = "(sites.E101) The SITE_ID setting must be an integer."\n with self.assertRaisesMessage(SystemCheckError, message):\n call_command("check")\nENABLE_ANALYTICS というカスタム設定が True に設定されていない場合に、デプロイ時に警告を発行する以下のチェックを考えてみましょう:
from django.conf import settings\nfrom django.core.checks import Warning, register\n\n\n@register("myapp", deploy=True)\ndef check_enable_analytics_is_true_on_deploy(app_configs, **kwargs):\n errors = []\n if getattr(settings, "ENABLE_ANALYTICS", None) is not True:\n errors.append(\n Warning(\n "The ENABLE_ANALYTICS setting should be set to True in deployment.",\n id="myapp.W001",\n )\n )\n return errors\nこのチェックが SystemCheckError を発生させないことを考えると、以下のように、 stderr の出力に警告メッセージがあることをアサートできます:
from io import StringIO\n\nfrom django.core.management import call_command\nfrom django.test import SimpleTestCase, override_settings\n\n\nclass EnableAnalyticsDeploymentCheckTest(SimpleTestCase):\n @override_settings(ENABLE_ANALYTICS=None)\n def test_when_set_to_none(self):\n stderr = StringIO()\n call_command("check", "-t", "myapp", "--deploy", stderr=stderr)\n message = (\n "(myapp.W001) The ENABLE_ANALYTICS setting should be set "\n "to True in deployment."\n )\n self.assertIn(message, stderr.getvalue())\n