Kerangka sistem pemeriksaan adalah kumpulan dari pemeriksaan tetap untuk memeriksa kebenaran proyek Django. Dia menemukan masalah umum dan menyediakan petunjuk untuk bagaimana memperbaiki mereka. Kerangka ini dapat diperpanjang sehingga anda dapat dengan mudah menambahkan pemeriksaan anda sendiri.
\nPemeriksaan dapat dibangkitkan jelas melalui perintah check. Pemeriksaan dipicu tidak langsung sebelum kebanyakan perintah, termasuk runserver dan migrate. Untuk alasan penampilan, pemeriksaan tidak berjalan sebagai bagian dari tumpukan WSGI yang digunakan dalam pengembangan. Jika anda butuh menjalankan pemeriksaan sistem pada peladen pengembangan anda, picu mereka dengan jelas menggunakan check.
Kesalahan-kesalahan serius akan mencegah perintah Django (seperti runserver) dari menjalankan sama sekali. Masalah-masalah dilaporkan ke konsol. Jika anda telah memeriksa penyebab dari peringatan dan senang mengabaikan itu, anda dapat memyembunyikan peringatan khusus menggunakan pengaturan SILENCED_SYSTEM_CHECKS di berkas pengaturan proyek anda.
Sebuah daftar penuh dari semua pemeriksaan yang dapat dimunculkan oleh Django dapat ditemukan di System check reference.
\nKerangka kerja fleksibel dan mengizinkan anda menulis fungsi-fungsi yang melakukan jenis lain pemeriksaan anda mungkin butuhkan. Berikut adalah sebuah contoh potongan fungsi pemeriksaan:
\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\nThe check function must accept an app_configs argument; this argument is\nthe list of applications that should be inspected. If None, the check must\nbe run on all installed apps in the project.
The check will receive a databases keyword argument. This is a list of\ndatabase aliases whose connections may be used to inspect database level\nconfiguration. If databases is None, the check must not use any\ndatabase connections.
Argumen **kwargs diperlukan untuk perluasan di masa mendatang.
Fungsi harus mengembalikan sebuah daftar pesan. Jika tidak ada masalah ditemukan sebagai hasil dari pemeriksaan, fungsi pemeriksaaan harus mengembalikan sebuah daftar kosong.
\nPeringatan dan kesalahan dimunculkan oleh metode pemeriksaan harus berupa instance dari CheckMessage. Sebuah instance dari CheckMessage membungkus kesalahan tunggal dilaporkan atau peringatan. Itu juga menyediakan konteks dan petunjuk dapat diterapkan ke pesan, dan penciri unik yang digunakan untuk tujuan penyaringan.
Konsep sangat mirip ke pasan dari message framework atau the logging framework. Pesan-pesan dietiket dengan level menunjukkan kekerasan pesan.
Ada juga jalan pintas untuk membuat pesan dengan tingkatan umum lebih mudah. Ketika menggunakan kelas-kelas ini anda dapat menghilangkan argumen level karena itu disisipkan oleh nama kelas.
Akhirnya, fungsi pemeriksaan anda harus terdaftar jelas dengan sistem pemeriksaan regristrar. Pemeriksaan harus didaftarkan dalam sebuah berkas yang dimuat ketika aplikasi anda dimuat; sebagai contoh, di metode AppConfig.ready().
Anda dapat melewatkan sebanyak etiket ke register seperti anda inginkan untuk melabelkan pemeriksaan anda. Pemeriksaan etiket sangat berguna sejak itu mengizinkan anda menjalankan hanya kelompok tertentu dari pemeriksaan. Sebagai contoh, untuk mendaftar pemeriksaan kesesuaian, anda akan membuat panggilan berikut:
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\nAnda dapat mendaftar "deployment checks" yang hanya bersangkutan pada berkas pengaturan produksi seperti ini:
\n@register(Tags.security, deploy=True)\ndef my_check(app_configs, **kwargs): ...\nPemeriksaan ini hanya akan dijalankan jika pilihan check --deploy digunakan.
Anda dapat juga menggunakan register sebagai sebuah fungsi daripada sebuah penghias dengan melewatkan obyek callable (biasanya sebuah fungsi) sebagai argumen pertama pada register
Kode dibawah ini setara dengan kode diatas:
\ndef my_check(app_configs, **kwargs): ...\n\n\nregister(my_check, Tags.security, deploy=True)\nDalam beberapa kasus, anda tidak butuh mendaftar fungsi pemeriksaan anda -- anda dapat mendukung pada pendaftaran yang ada.
\nFields, constraints, models, model managers, template engines, task backends,\nand database backends all implement a check() method that is already\nregistered with the check framework. If you want to add extra checks, you can\nextend the implementation on the base class, perform any extra checks you need,\nand append any messages to those generated by the base class. It's recommended\nthat you delegate each check to separate methods.
Pertimbangkan sebuah contoh dimana anda sedang menerapkan bidang penyesuaian bernama RangedIntegerField. Bidang ini menambahkan argumen min dan max pada pembangun dari IntegerField. Anda mungkin ingin menambah sebuah pemeriksaan untuk memastikan bahwa pengguna menyediakan nilai minimal yang kurang atau setara pada nilai maksimal. Potongan kode berikut menunjukkan anda dapat menerapkan pemeriksaan ini:
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 []\nJika anda ingin menambah pemeriksaan pada pengelola model, anda akan mengambil pendekatan sama pada subkelas anda dari Manager.
Jika anda ingin menambah sebuah pemeriksaan pada kelas model, pendekatan adalah hampir sama: perbedaan hanya bahwa pemeriksaan adalah metode kelas, bukan metode instance:
\nclass MyModel(models.Model):\n @classmethod\n def check(cls, **kwargs):\n errors = super().check(**kwargs)\n # ... your own checks ...\n return errors\nPesan dapat dibandingkan. Itu mengizinakan anda dengan mudah menulis percobaan:
\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)\nGiven the need to register certain checks when the application loads, it can be\nuseful to test their integration within the system checks framework. This can\nbe accomplished by using the call_command()\nfunction.
For example, this test demonstrates that the SITE_ID setting must be\nan integer, a built-in check from the sites framework:
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")\nConsider the following check which issues a warning on deployment if a custom\nsetting named ENABLE_ANALYTICS is not set to 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\nGiven that this check will not raise a SystemCheckError, the presence of\nthe warning message in the stderr output can be asserted like so:
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