Ramverket System Check är en uppsättning statiska kontroller för validering av Django-projekt. Det upptäcker vanliga problem och ger tips om hur man åtgärdar dem. Ramverket är utbyggbart så att du enkelt kan lägga till dina egna kontroller.
\nKontroller kan utlösas explicit via kommandot check. Kontroller utlöses implicit före de flesta kommandon, inklusive runserver och migrate. Av prestandaskäl körs inte kontrollerna som en del av WSGI-stacken som används vid distributionen. Om du behöver köra systemkontroller på din distributionsserver ska du utlösa dem explicit med check.
Allvarliga fel förhindrar Django-kommandon (t.ex. runserver) från att köras överhuvudtaget. Mindre problem rapporteras till konsolen. Om du har undersökt orsaken till en varning och gärna ignorerar den, kan du dölja specifika varningar med hjälp av inställningen SILENCED_SYSTEM_CHECKS i projektets inställningsfil.
En fullständig lista över alla kontroller som kan ställas in av Django finns i Systemkontrollreferens.
\nRamverket är flexibelt och låter dig skriva funktioner som utför alla andra typer av kontroller som du kan tänkas behöva. Följande är ett exempel på en stubkontrollfunktion:
\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\nCheck-funktionen måste acceptera ett app_configs-argument; detta argument är listan över applikationer som ska inspekteras. Om None, måste kontrollen köras på alla installerade appar i projektet.
Kontrollen får ett argument i form av nyckelordet databases. Detta är en lista över databasalias vars anslutningar kan användas för att inspektera konfigurationen på databasnivå. Om databases är None får kontrollen inte använda några databasanslutningar.
Argumentet **kwargs är nödvändigt för framtida expansion.
Funktionen måste returnera en lista med meddelanden. Om inga problem hittas som ett resultat av kontrollen, måste check-funktionen returnera en tom lista.
\nDe varningar och fel som checkmetoden ger upphov till måste vara instanser av CheckMessage. En instans av CheckMessage kapslar in ett enda rapporterbart fel eller varning. Det ger också sammanhang och tips som är tillämpliga på meddelandet och en unik identifierare som används för filtreringsändamål.
Konceptet är mycket likt meddelanden från message framework eller logging framework. Meddelanden taggas med en nivå som anger hur allvarligt meddelandet är.
Det finns också genvägar som gör det enklare att skapa meddelanden med gemensamma nivåer. När du använder dessa klasser kan du utelämna argumentet level eftersom det är underförstått av klassnamnet.
Slutligen måste din kontrollfunktion registreras uttryckligen med systemets kontrollregister. Kontroller bör registreras i en fil som laddas när din applikation laddas; till exempel i metoden AppConfig.ready().
Du kan skicka så många taggar till register som du vill för att märka din kontroll. Att märka kontroller är användbart eftersom det gör att du bara kan köra en viss grupp av kontroller. Om du t.ex. vill registrera en kompatibilitetskontroll gör du följande anrop:
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\nDu kan registrera ”deployment checks” som endast är relevanta för en produktionsinställningsfil på följande sätt:
\n@register(Tags.security, deploy=True)\ndef my_check(app_configs, **kwargs): ...\nDessa kontroller kommer endast att köras om alternativet check --deploy används.
Du kan också använda register som en funktion i stället för en dekorator genom att skicka ett anropsbart objekt (vanligtvis en funktion) som första argument till register.
Koden nedan är likvärdig med koden ovan:
\ndef my_check(app_configs, **kwargs): ...\n\n\nregister(my_check, Tags.security, deploy=True)\nI vissa fall behöver du inte registrera din checkfunktion - du kan använda dig av en befintlig registrering.
\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.
Tänk på ett exempel där du implementerar ett anpassat fält med namnet RangedIntegerField. Det här fältet lägger till argumenten min och max i konstruktören för IntegerField. Du kanske vill lägga till en kontroll för att se till att användarna anger ett min-värde som är mindre än eller lika med max-värdet. Följande kodutdrag visar hur du kan implementera denna kontroll:
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 []\nOm du vill lägga till kontroller till en modellhanterare skulle du använda samma tillvägagångssätt på din underklass av Manager.
Om du vill lägga till en kontroll i en modellklass är tillvägagångssättet nästan detsamma: den enda skillnaden är att kontrollen är en klassmetod, inte en instansmetod:
\nclass MyModel(models.Model):\n @classmethod\n def check(cls, **kwargs):\n errors = super().check(**kwargs)\n # ... your own checks ...\n return errors\nMeddelanden är jämförbara. Det gör att du enkelt kan skriva tester:
\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)\nMed tanke på behovet av att registrera vissa kontroller när applikationen laddas kan det vara användbart att testa deras integration inom ramverket för systemkontroller. Detta kan åstadkommas genom att använda funktionen call_command().
Det här testet visar till exempel att inställningen SITE_ID måste vara ett heltal, en inbyggd check från sites-ramverket:
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")\nTänk på följande kontroll som ger en varning vid distribution om en anpassad inställning med namnet ENABLE_ANALYTICS inte är inställd på 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\nMed tanke på att denna kontroll inte kommer att ge upphov till ett SystemCheckError, kan förekomsten av varningsmeddelandet i stderr-utdata hävdas på följande sätt:
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