django-admin och manage.py

django-admin är Djangos kommandoradsverktyg för administrativa uppgifter. Detta dokument beskriver allt det kan göra.

Dessutom skapas manage.py automatiskt i varje Django-projekt. Den gör samma sak som django-admin men ställer också in miljövariabeln DJANGO_SETTINGS_MODULE så att den pekar på ditt projekts settings.py-fil.

Skriptet django-admin bör finnas på din systemsökväg om du installerade Django via pip. Om det inte finns i din sökväg, se till att du har aktiverat din virtuella miljö.

När du arbetar med ett enda Django-projekt är det i allmänhet lättare att använda manage.py än django-admin. Om du behöver växla mellan flera Django-inställningsfiler, använd django-admin med DJANGO_SETTINGS_MODULE eller kommandoradsalternativet --settings.

I kommandoradsexemplen i det här dokumentet används django-admin för att vara konsekvent, men alla exempel kan lika gärna använda manage.py eller python -m django.

Användning

Linux/macOS

$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]

Windows

...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]

command ska vara ett av de kommandon som listas i detta dokument. options, som är valfritt, ska vara noll eller flera av de alternativ som finns tillgängliga för det angivna kommandot.

Få hjälp under körtiden

django-admin help

Kör django-admin help för att visa användningsinformation och en lista över de kommandon som tillhandahålls av varje program.

Kör django-admin help --commands för att visa en lista över alla tillgängliga kommandon.

Kör django-admin help <command> för att visa en beskrivning av det angivna kommandot och en lista över dess tillgängliga alternativ.

Appens namn

Många kommandon tar emot en lista med ”appnamn” Ett ”appnamn” är basnamnet på det paket som innehåller dina modeller. Om din INSTALLED_APPS till exempel innehåller strängen 'mysite.blog', är appnamnet blog.

Fastställande av version

django-admin version

Kör django-admin version för att visa den aktuella Django-versionen.

Utdata följer det schema som beskrivs i PEP 440:

1.4.dev17026
1.4a1
1.4

Visning av debug-utdata

Använd --verbosity, där det stöds, för att ange mängden meddelande- och felsökningsinformation som django-admin skriver ut till konsolen.

Tillgängliga kommandon

kontroll

django-admin check [app_label [app_label ...]]

Använder systemkontrollramverket för att inspektera hela Django-projektet för vanliga problem.

Som standard kommer alla appar att kontrolleras. Du kan kontrollera en delmängd av appar genom att ange en lista med appetiketter som argument:

django-admin check auth admin myapp

--tag TAGS, -t TAGS

Ramverket för systemkontroller utför många olika typer av kontroller som är kategoriserade med taggar. Du kan använda dessa taggar för att begränsa de kontroller som utförs till att bara omfatta kontroller i en viss kategori. Om du t.ex. bara vill utföra kontroller av modeller och kompatibilitet kör du:

django-admin check --tag models --tag compatibility

--database DATABASE

Anger den databas där kontroller som kräver databasåtkomst ska utföras:

django-admin check --database default --database other

Som standard kommer dessa kontroller inte att köras.

--list-tags

Visar en lista över alla tillgängliga taggar.

--deploy

Aktiverar några ytterligare kontroller som endast är relevanta i en distributionsinställning.

Du kan använda detta alternativ i din lokala utvecklingsmiljö, men eftersom din lokala inställningsmodul för utveckling kanske inte har många av dina produktionsinställningar, kommer du förmodligen att vilja rikta kommandot check mot en annan inställningsmodul, antingen genom att ange miljövariabeln DJANGO_SETTINGS_MODULE eller genom att ange alternativet --settings:

django-admin check --deploy --settings=production_settings

Eller så kan du köra det direkt på en produktions- eller staging-distribution för att verifiera att rätt inställningar används (genom att utelämna --settings). Du kan till och med göra det till en del av din integrationstestsvit.

--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}

Anger den meddelandenivå som gör att kommandot avslutas med en status som inte är noll. Standard är ERROR.

compilemessages

django-admin compilemessages

Kompilerar .po-filer skapade av makemessages till .mo-filer för användning med det inbyggda gettext-stödet. Se Internationalisering och lokalisering.

--locale LOCALE, -l LOCALE

Anger den eller de lokala språkversioner som ska bearbetas. Om inget anges bearbetas alla lokala språk.

--exclude EXCLUDE, -x EXCLUDE

Anger den eller de lokala språkversioner som ska undantas från bearbetning. Om inget anges utesluts inga lokala språk.

--use-fuzzy, -f

Inkluderar fuzzy translations i kompilerade filer.

Exempel på användning:

django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr

--ignore PATTERN, -i PATTERN

Ignorerar kataloger som matchar det angivna glob-stilmönstret. Använd flera gånger för att ignorera fler.

Exempel på användning:

django-admin compilemessages --ignore=cache --ignore=outdated/*/locale

`skapa en mottagare

django-admin createcachetable

Skapar cachetabellerna för användning med databasens cache-backend med hjälp av informationen från din inställningsfil. Se Djangos ramverk för cache för mer information.

--database DATABASE

Anger den databas i vilken cachetabellen/-tabellerna ska skapas. Standardvärdet är default.

--dry-run

Skriver ut den SQL som ska köras utan att faktiskt köra den, så att du kan anpassa den eller använda migreringsramverket.

dbshell

django-admin dbshell

Kör kommandoradsklienten för den databasmotor som anges i inställningen ENGINE, med de anslutningsparametrar som anges i inställningarna USER, PASSWORD, etc.

• För PostgreSQL kör detta kommandoradsklienten `` psql``.

• För MySQL körs kommandoradsklienten mysql.

• För SQLite körs kommandoradsklienten sqlite3.

• För Oracle körs kommandoradsklienten sqlplus.

Detta kommando förutsätter att programmen finns i din PATH så att ett anrop till programnamnet (psql, mysql, sqlite3, sqlplus) hittar programmet på rätt plats. Det finns inget sätt att ange platsen för programmet manuellt.

--database DATABASE

Anger den databas där ett skal ska öppnas. Standardvärdet är default.

-- ARGUMENTS

Alla argument som följer en `` —`` avdelare kommer att vidarebefordras till den underliggande kommandoradsklienten. Till exempel:, med PostgreSQL kan du använda kommandot `` psql`` kommandots `` c`` flagga för att köra en rå SQL-fråga direkt:

Linux/macOS

$ django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

Windows

...\> django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)

På MySQL/MariaDB kan du göra detta med kommandot mysql flagga -e:

Linux/macOS

$ django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

Windows

...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+

Observera

Tänk på att inte alla alternativ som anges i OPTIONS-delen av din databaskonfiguration i DATABASES skickas till kommandoradsklienten, t.ex. 'isolation_level'.

differensinställningar

django-admin diffsettings

Visar skillnader mellan den aktuella inställningsfilen och Djangos standardinställningar (eller en annan inställningsfil som anges av --default).

Inställningar som inte finns med i standardinställningarna följs av "###". Standardinställningarna definierar till exempel inte ROOT_URLCONF, så ROOT_URLCONF följs av "###" i utdata från diffsettings.

--all

Visar alla inställningar, även om de har Djangos standardvärde. Sådana inställningar inleds med "###".

--default MODULE

Den inställningsmodul som de aktuella inställningarna ska jämföras med. Lämna tom för att jämföra mot Djangos standardinställningar.

--output {hash,unified}

Anger utdataformat. Tillgängliga värden är hash och unified. hash är standardläget som visar utdata enligt beskrivningen ovan. unified visar utdata som liknar diff -u. Standardinställningar inleds med ett minustecken, följt av den ändrade inställningen som inleds med ett plustecken.

Dumpdata

django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]

Skickar ut alla data i databasen som är kopplade till de namngivna programmen till standardutdata.

Om inget applikationsnamn anges kommer alla installerade applikationer att dumpas.

Utdata från dumpdata kan användas som indata för loaddata.

När resultatet av dumpdata sparas som en fil kan den fungera som en fixtur för tester eller som en initial data.

Observera att dumpdata använder standardhanteraren i modellen för att välja vilka poster som ska dumpas. Om du använder en :ref:custom manager <custom-managers> som standardhanterare och den filtrerar några av de tillgängliga posterna, kommer inte alla objekt att dumpas.

--all, -a

Använder Djangos bashanterare och dumpar poster som annars skulle kunna filtreras eller ändras av en anpassad hanterare.

--format FORMAT

Anger serialiseringsformatet för utdata. Standardvärdet är JSON. Format som stöds listas i Format för serialisering.

--indent INDENT

Anger antalet indragningsutrymmen som ska användas i utdata. Standardvärdet är None som visar alla data på en enda rad.

--exclude EXCLUDE, -e EXCLUDE

Förhindrar att specifika program eller modeller (anges i form av app_label.ModelName) dumpas. Om du anger ett modellnamn är det bara den modellen som utesluts, inte hela programmet. Du kan också blanda programnamn och modellnamn.

Om du vill utesluta flera program, skicka --exclude mer än en gång:

django-admin dumpdata --exclude=auth --exclude=contenttypes

--database DATABASE

Anger den databas från vilken data ska dumpas. Standardvärdet är default.

--natural-foreign

Använder modellmetoden natural_key() för att serialisera alla foreign key och many-to-many-relationer till objekt av den typ som definierar metoden. Om du dumpar contrib.auth Permission-objekt eller contrib.contenttypes ContentType-objekt bör du förmodligen använda den här flaggan. Se :ref:``natural keys <topics-serialization-natural-keys>`-dokumentationen för mer information om detta och nästa alternativ.

--natural-primary

Utelämnar primärnyckeln i de serialiserade data för detta objekt eftersom den kan beräknas under deserialiseringen.

--pks PRIMARY_KEYS

Skickar endast ut de objekt som anges i en kommaseparerad lista med primärnycklar. Detta är endast tillgängligt vid dumpning av en modell. Som standard matas alla poster i modellen ut.

--output OUTPUT, -o OUTPUT

Anger en fil som de serialiserade data ska skrivas till. Som standard går data till standardutdata.

När detta alternativ är inställt och --verbosity är större än 0 (standard), visas en förloppsindikator i terminalen.

Komprimering av fixturer

Utdatafilen kan komprimeras med något av formaten bz2, gz, lzma eller xz genom att avsluta filnamnet med motsvarande tillägg. Till exempel:, för att mata ut data som en komprimerad JSON-fil:

django-admin dumpdata -o mydata.json.gz

spola

django-admin flush

Tar bort alla data från databasen och kör om alla postsynkroniseringshanterare. Tabellen över vilka migreringar som har tillämpats rensas inte.

Om du hellre vill starta från en tom databas och köra alla migreringar på nytt bör du ta bort och återskapa databasen och sedan köra migrate istället.

--noinput, --no-input

Undertrycker alla användarinstruktioner.

--database DATABASE

Anger vilken databas som ska rensas. Standardvärdet är default.

inspectdb

django-admin inspectdb [table [table ...]]

Introspekterar databastabellerna i databasen som pekas ut av inställningen NAME och matar ut en Django-modellmodul (en models.py-fil) till standardutdata.

Du kan välja vilka tabeller eller vyer som ska inspekteras genom att ange deras namn som argument. Om inga argument anges skapas modeller för vyer endast om alternativet --include-views används. Modeller för partitionstabeller skapas på PostgreSQL om alternativet --include-partitions används.

Använd detta om du har en äldre databas som du vill använda Django med. Skriptet kommer att inspektera databasen och skapa en modell för varje tabell i den.

Som du kanske förväntar dig kommer de skapade modellerna att ha ett attribut för varje fält i tabellen. Observera att inspectdb har några specialfall i sin fältnamnsutmatning:

• Om inspectdb inte kan mappa en kolumns typ till en modellfälttyp, kommer den att använda TextField och infoga Python-kommentaren 'Denna fälttyp är en gissning.' bredvid fältet i den genererade modellen. De fält som identifieras kan bero på appar som listas i INSTALLED_APPS. Till exempel: lägger django.contrib.postgres till igenkänning för flera PostgreSQL-specifika fälttyper.

• Om databasens kolumnnamn är ett reserverat Python-ord (som 'pass', 'class' eller 'for'), kommer inspectdb att lägga till '_field' till attributnamnet. Om en tabell till exempel har kolumnen 'for', kommer den genererade modellen att ha fältet 'for_field', med attributet db_column inställt på 'for'. inspectdb kommer att infoga Python-kommentaren 'Fältet döptes om eftersom det var ett reserverat Python-ord.' bredvid fältet.

Den här funktionen är tänkt som en genväg, inte som en slutgiltig modellgenerering. När du har kört den bör du själv titta igenom de genererade modellerna för att göra anpassningar. Framför allt behöver du ändra modellernas ordning så att modeller som hänvisar till andra modeller får rätt ordning.

Django skapar inte standardvärden för databaser när en default anges för ett modellfält. På samma sätt översätts inte databasstandardvärden till standardvärden för modellfält eller upptäcks på något sätt av inspectdb.

Som standard skapar inspectdb ohanterade modeller. Det vill säga, managed = False i modellens Meta-klass säger till Django att inte hantera varje tabells skapande, modifiering och radering. Om du vill tillåta Django att hantera tabellens livscykel måste du ändra alternativet managed till True (eller ta bort det eftersom True är dess standardvärde).

Databasspecifika anteckningar

Oracle

• Modeller skapas för materialiserade vyer om --include-views används.

PostgreSQL

• Modeller skapas för utländska tabeller.

• Modeller skapas för materialiserade vyer om --include-views används.

• Modeller skapas för partitionstabeller om --include-partitions används.

--database DATABASE

Anger vilken databas som ska introspekteras. Standardvärdet är default.

--include-partitions

Om detta alternativ anges skapas även modeller för partitioner.

Endast stöd för PostgreSQL är implementerat.

--include-views

Om detta alternativ anges skapas även modeller för databasvyer.

Ladda data

django-admin loaddata fixture [fixture ...]

Söker efter och laddar innehållet i den namngivna fixture i databasen.

--database DATABASE

Anger den databas som data ska laddas till. Standardvärdet är default.

--ignorenonexistent, -i

Ignorerar fält och modeller som kan ha tagits bort sedan fixturen ursprungligen skapades.

--app APP_LABEL

Anger en enda app att leta efter fixturer i istället för att leta i alla appar.

--format FORMAT

Anger serialiseringsformat (t.ex. json eller xml) för fixturer läs från stdin.

--exclude EXCLUDE, -e EXCLUDE

Utesluter laddning av fixturerna från de angivna applikationerna och/eller modellerna (i form av app_label eller app_label.ModelName). Använd alternativet flera gånger för att utesluta mer än en app eller modell.

Laddar fixturer från stdin

Du kan använda ett bindestreck som fixturnamn för att ladda inmatning från sys.stdin. Till exempel:

django-admin loaddata --format=json -

Vid läsning från stdin krävs alternativet --format för att ange serialiseringsformat för indata (t.ex. json eller xml).

Att ladda från stdin är användbart med omdirigeringar av standardinmatning och -utmatning. Till exempel:

django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -

Kommandot dumpdata kan användas för att generera indata för loaddata.

Se även

Mer information om fixturer finns i ämnet Fixturer.

makemessages

django-admin makemessages

Går igenom hela källträdet i den aktuella katalogen och drar ut alla strängar som är markerade för översättning. Den skapar (eller uppdaterar) en meddelandefil i katalogen conf/locale (i Django-trädet) eller locale (för projekt och program). När du har gjort ändringar i meddelandefilerna måste du kompilera dem med compilemessages för användning med det inbyggda gettext-stödet. Se i18n documentation för mer information.

Det här kommandot kräver inga konfigurerade inställningar. Men när inställningarna inte är konfigurerade kan kommandot inte ignorera katalogerna MEDIA_ROOT och STATIC_ROOT eller inkludera LOCALE_PATHS.

--all, -a

Uppdaterar meddelandefilerna för alla tillgängliga språk.

--extension EXTENSIONS, -e EXTENSIONS

Anger en lista med filändelser som ska undersökas (standard: html, txt, py eller js om --domain är djangojs).

Exempel på användning:

django-admin makemessages --locale=de --extension xhtml

Separera flera tillägg med kommatecken eller använd -e eller --extension flera gånger:

django-admin makemessages --locale=de --extension=html,txt --extension xml

--locale LOCALE, -l LOCALE

Anger den eller de locale(s) som ska bearbetas.

--exclude EXCLUDE, -x EXCLUDE

Anger den eller de lokala språkversioner som ska undantas från bearbetning. Om inget anges utesluts inga lokala språk.

Exempel på användning:

django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr

--domain DOMAIN, -d DOMAIN

Anger domänen för meddelandefilerna. Alternativ som stöds är:

• django för alla *.py, *.html och *.txt-filer (standard)

• djangojs för *.js-filer

--symlinks, -s

Följer symlinks till kataloger när du letar efter nya översättningssträngar.

Exempel på användning:

django-admin makemessages --locale=de --symlinks

--ignore PATTERN, -i PATTERN

Ignorerar filer eller kataloger som matchar det angivna glob-stilmönstret. Använd flera gånger för att ignorera fler.

Dessa mönster används som standard: 'CVS', '.*', '*~', '*.pyc'.

Exempel på användning:

django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

--no-default-ignore

Inaktiverar standardvärdena för --ignore.

--no-wrap

Avaktiverar uppdelning av långa meddelanderader i flera rader i språkfiler.

--no-location

Undertrycker skrivning av ”#: filnamn:rad”-kommentarrader i språkfiler. Om du använder detta alternativ blir det svårare för tekniskt skickliga översättare att förstå varje meddelandes sammanhang.

--add-location [{full,file,never}]

Styr #: filnamn:rad kommentarrader i språkfiler. Om alternativet är:

• full (standard om den inte anges): raderna innehåller både filnamn och radnummer.

• file: radnumret utelämnas.

• never: raderna undertrycks (samma som --no-location).

Kräver gettext 0.19 eller nyare.

--no-obsolete

Tar bort föråldrade meddelandesträngar från filerna .po.

--keep-pot

Förhindrar att de temporära .pot-filerna som genereras innan .po-filen skapas raderas. Detta är användbart vid felsökning av fel som kan förhindra att de slutliga språkfilerna skapas.

Se även

Se Anpassa kommandot ”Makemessages för instruktioner om hur du anpassar de nyckelord som makemessages skickar till xgettext.

makemigreringar

django-admin makemigrations [app_label [app_label ...]]

Skapar nya migreringar baserat på de ändringar som upptäcks i dina modeller. Migreringar, deras förhållande till appar med mera behandlas ingående i dokumentationen om migreringar.

Om du anger ett eller flera appnamn som argument begränsas de migreringar som skapas till den eller de angivna apparna och eventuella beroenden som behövs (t.ex. tabellen i andra änden av en ForeignKey).

Om du vill lägga till migreringar i en app som inte har en katalog med namnet migrations kör du makemigrations med appens app_label.

--noinput, --no-input

Undertrycker alla användarinstruktioner. Om en undertryckt fråga inte kan lösas automatiskt avslutas kommandot med felkod 3.

--empty

Skriver ut en tom migrering för de angivna apparna, för manuell redigering. Detta är för avancerade användare och bör inte användas om du inte är bekant med migreringsformatet, migreringsåtgärderna och beroendena mellan dina migreringar.

--dry-run

Visar vilka migreringar som skulle göras utan att några migreringsfiler faktiskt skrivs till disken. Om du använder detta alternativ tillsammans med --verbosity 3 visas även de fullständiga migreringsfiler som skulle skrivas.

--merge

Gör det möjligt att åtgärda migrationskonflikter.

--name NAME, -n NAME

Tillåter namngivning av genererade migreringar istället för att använda ett genererat namn. Namnet måste vara en giltig Python identifierare.

--no-header

Generera migreringsfiler utan Django-version och tidsstämpelhuvud.

--check

Gör att makemigrations avslutas med en status som inte är noll när modelländringar utan migreringar upptäcks. Innebär --dry-run.

--scriptable

Omdirigerar loggutdata och inmatningsfrågor till stderr och skriver endast sökvägar för genererade migreringsfiler till stdout.

--update

Sammanfogar modelländringar till den senaste migreringen och optimerar de resulterande operationerna.

Den uppdaterade migreringen kommer att ha ett genererat namn. För att bevara det tidigare namnet, ställ in det med --name.

migrera

django-admin migrate [app_label] [migration_name]

Synkroniserar databastillståndet med den aktuella uppsättningen modeller och migreringar. Migreringar, deras förhållande till appar med mera behandlas ingående i dokumentationen om migreringar.

Kommandot fungerar på olika sätt beroende på vilka argument som anges:

• Inga argument: Alla appar har alla sina migreringar körda.

• <app_label>: Den angivna appen får sina migreringar körda, fram till den senaste migreringen. Detta kan innebära att andra appars migreringar också körs, på grund av beroenden.

• <app_label> <migrationname>: För databasschemat till ett tillstånd där den namngivna migreringen tillämpas, men inga senare migreringar i samma app tillämpas. Detta kan innebära att migreringar inte tillämpas om du tidigare har migrerat förbi den namngivna migreringen. Du kan använda ett prefix för migreringsnamnet, t.ex. 0001, så länge det är unikt för det angivna appnamnet. Använd namnet zero för att migrera hela vägen tillbaka, dvs. för att återställa alla tillämpade migreringar för en app.

Varning

När migreringar tas bort kommer alla beroende migreringar också att tas bort, oavsett <app_label>. Du kan använda --plan för att kontrollera vilka migreringar som inte kommer att tillämpas.

--database DATABASE

Anger den databas som ska migreras. Standardvärdet är default.

--fake

Markerar migreringarna upp till målet (enligt reglerna ovan) som tillämpade, men utan att faktiskt köra SQL för att ändra ditt databasschema.

Detta är avsett för avancerade användare som vill manipulera det aktuella migreringstillståndet direkt om de manuellt tillämpar ändringar; varnas för att användning av --fake riskerar att sätta migreringstillståndstabellen i ett tillstånd där manuell återställning kommer att krävas för att migreringarna ska fungera korrekt.

--fake-initial

Tillåter Django att hoppa över en apps första migrering om alla databastabeller med namnen på alla modeller som skapats av alla CreateModel-operationer i den migreringen redan finns. Det här alternativet är avsett att användas när migreringar körs för första gången mot en databas som inte tidigare använde migreringar. Det här alternativet kontrollerar dock inte att databasschemat matchar utöver matchande tabellnamn och är därför bara säkert att använda om du är säker på att ditt befintliga schema matchar det som registreras i din första migrering.

--plan

Visar de migreringsåtgärder som kommer att utföras för det angivna kommandot migrate.

--run-syncdb

Gör det möjligt att skapa tabeller för appar utan migreringar. Även om detta inte rekommenderas är migreringsramverket ibland för långsamt i stora projekt med hundratals modeller.

--noinput, --no-input

Undertrycker alla användarinstruktioner. Ett exempel är en fråga om att ta bort inaktuella innehållstyper.

--check

Gör att migrate avslutas med en status som inte är noll när oanvända migreringar upptäcks.

--prune

Raderar icke-existerande migreringar från tabellen django_migrations. Detta är användbart när migreringsfiler som ersatts av en krossad migrering har tagits bort. Se Minska antalet migreringar för mer information.

optimera migreringen

django-admin optimizemigration app_label migration_name

Optimerar åtgärderna för den namngivna migreringen och åsidosätter den befintliga filen. Om migreringen innehåller funktioner som måste kopieras manuellt skapar kommandot en ny migreringsfil med suffixet _optimized som är avsedd att ersätta den namngivna migreringen.

--check

Gör att optimizemigration avslutas med en status som inte är noll när en migrering kan optimeras.

runserver

django-admin runserver [addrport]

Startar en lättviktig webbserver för utveckling på den lokala maskinen. Som standard körs servern på port 8000 på IP-adressen 127.0.0.1. Du kan ange en IP-adress och ett portnummer explicit.

Om du kör det här skriptet som en användare med normala privilegier (rekommenderas) kanske du inte har tillgång till att starta en port på ett lågt portnummer. Låga portnummer är reserverade för superanvändaren (root).

Den här servern använder det WSGI-applikationsobjekt som anges i inställningen WSGI_APPLICATION.

Varning

ANVÄND INTE DENNA SERVER I EN PRODUKTIONSMILJÖ.

Denna lätta utvecklingsserver har inte genomgått säkerhetsgranskningar eller prestandatester och är därför olämplig för produktion. Att göra den här servern kapabel att hantera en produktionsmiljö ligger utanför Djangos omfattning.

Utvecklingsservern laddar automatiskt om Python-koden för varje begäran, efter behov. Du behöver inte starta om servern för att kodändringar ska träda i kraft. Vissa åtgärder, som att lägga till filer, utlöser dock inte en omstart, så du måste starta om servern i dessa fall.

Om du använder Linux eller MacOS och installerar både pywatchman och Watchman-tjänsten, kommer kernelsignaler att användas för att autoladda servern (i stället för att polla tidsstämplar för filändringar varje sekund). Detta ger bättre prestanda i stora projekt, minskad svarstid efter kodändringar, mer robust ändringsdetektering och minskad energianvändning. Django stöder pywatchman 1.2.0 och högre.

Stora kataloger med många filer kan orsaka prestandaproblem

När Watchman används i ett projekt som innehåller stora icke-Python-kataloger som node_modules, är det lämpligt att ignorera denna katalog för optimal prestanda. Se watchman documentation för information om hur du gör detta.

Timeout för vaktman

DJANGO_WATCHMAN_TIMEOUT

Standardtimeouten för Watchman-klienten är 5 sekunder. Du kan ändra den genom att ställa in miljövariabeln DJANGO_WATCHMAN_TIMEOUT.

När du startar servern, och varje gång du ändrar Python-kod medan servern körs, kommer ramverket för systemkontroll att kontrollera hela ditt Django-projekt för några vanliga fel (se kommandot check). Om några fel hittas kommer de att skrivas ut till standardutmatningen. Du kan använda alternativet --skip-checks för att hoppa över att köra systemkontroller.

Du kan köra så många samtidiga servrar som du vill, så länge de är på separata portar genom att köra django-admin runserver mer än en gång.

Observera att standard-IP-adressen, 127.0.0.1, inte är tillgänglig från andra maskiner i nätverket. Om du vill att utvecklingsservern ska kunna ses av andra datorer i nätverket använder du dess egen IP-adress (t.ex. 192.168.2.1), 0 (genväg för 0.0.0.0), 0.0.0.0 eller :: (med IPv6 aktiverat).

Du kan ange en IPv6-adress omgiven av parenteser (t.ex. [200a::1]:8000). Detta aktiverar automatiskt IPv6-stöd.

Ett värdnamn som endast innehåller ASCII-tecken kan också användas.

Om contrib-appen staticfiles är aktiverad (standard i nya projekt) kommer kommandot runserver att åsidosättas med sitt eget kommando runserver.

Loggning av varje begäran och svar från servern skickas till loggern django.server.

--noreload

Inaktiverar den automatiska omladdaren. Detta innebär att eventuella ändringar i Python-koden som du gör medan servern körs inte kommer att träda i kraft om de specifika Python-modulerna redan har laddats in i minnet.

--nothreading

Inaktiverar användning av trådning i utvecklingsservern. Servern är flertrådig som standard.

--ipv6, -6

Använder IPv6 för utvecklingsservern. Detta ändrar standard-IP-adressen från 127.0.0.1 till ::1.

DJANGO_RUNSERVER_HIDE_WARNING

New in Django 5.2.

Som standard skrivs en varning ut till konsolen om att runserver inte är lämplig för produktion:

WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
For more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/

Ställ in denna miljövariabel på "true" för att dölja denna varning.

Exempel på användning av olika portar och adresser

Port 8000 på IP-adress 127.0.0.1:

django-admin runserver

Port 8000 på IP-adress 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Port 7000 på IP-adress 127.0.0.1:

django-admin runserver 7000

Port 7000 på IP-adress 1.2.3.4:

django-admin runserver 1.2.3.4:7000

Port 8000 på IPv6-adress ::1:

django-admin runserver -6

Port 7000 på IPv6-adress ::1:

django-admin runserver -6 7000

Port 7000 på IPv6-adressen 2001:0db8:1234:5678::9:

django-admin runserver [2001:0db8:1234:5678::9]:7000

Port 8000 på IPv4-adressen för värden localhost:

django-admin runserver localhost:8000

Port 8000 på IPv6-adressen för värden localhost:

django-admin runserver -6 localhost:8000

Servering av statiska filer med utvecklingsservern

Som standard serverar utvecklingsservern inte några statiska filer för din webbplats (t.ex. CSS-filer, bilder, saker under MEDIA_URL och så vidare). Om du vill konfigurera Django för att servera statiska media, läs Hur man hanterar statiska filer (t.ex. bilder, JavaScript, CSS).

Tjänstgöring med ASGI under utveckling

Djangos kommando runserver tillhandahåller en WSGI-server. För att kunna köra under ASGI måste du använda en ASGI-server. Django Daphne-projektet tillhandahåller Integration med runserver som du kan använda.

sendtestemail

django-admin sendtestemail [email [email ...]]

Skickar ett testmejl (för att bekräfta att det fungerar att skicka e-post via Django) till den eller de mottagare som anges. Till exempel:

django-admin sendtestemail [e-mail] [e-mail]

Det finns ett par alternativ, och du kan använda vilken kombination som helst av dem tillsammans:

--managers

Skickar e-post till de e-postadresser som anges i MANAGERS med mail_managers().

--admins

Skickar e-post till de e-postadresser som anges i ADMINS med mail_admins().

shell

django-admin shell

Startar den interaktiva Python-tolken.

Alla modeller från installerade appar importeras automatiskt till skalmiljön. Modeller från appar som listats tidigare i INSTALLED_APPS har företräde. För en --verbosity på 2 eller högre kommer de automatiskt importerade objekten att listas. För att helt avaktivera automatisk import, använd flaggan --no-imports.

Se guiden :ref:``Anpassa det här beteendet <customizing-shell-auto-imports>` för att lägga till eller ta bort automatisk import.

Changed in Django 5.2:

Automatisk import av modeller har lagts till.

--interface {ipython,bpython,python}, -i {ipython,bpython,python}

Anger vilket shell som ska användas. Som standard kommer Django att använda IPython eller bpython om något av dem är installerat. Om båda är installerade, ange vilket du vill ha så här:

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

Om du har ett ”rikt” skal installerat men vill tvinga fram användning av den ”vanliga” Python-tolken använder du python som gränssnittsnamn, så här:

django-admin shell -i python

--no-startup

Inaktiverar läsning av startskriptet för den ”vanliga” Python-tolken. Som standard läses det skript som pekas ut av miljövariabeln PYTHONSTARTUP eller skriptet ~/.pythonrc.py.

--no-imports

New in Django 5.2.

Avaktiverar automatisk import av modeller från INSTALLED_APPS.

--command COMMAND, -c COMMAND

Låter dig skicka ett kommando som en sträng för att exekvera det som Django, så här:

django-admin shell --command="import django; print(django.__version__)"

Du kan också skicka in kod på standardinmatningen för att köra den. Till exempel:

$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF

På Windows matas REPL ut på grund av begränsningar i implementeringen av select.select() på den plattformen.

visa migreringar

django-admin showmigrations [app_label [app_label ...]]

Visar alla migreringar i ett projekt. Du kan välja ett av två format:

--list, -l

Visar alla appar som Django känner till, de migreringar som är tillgängliga för varje app och om varje migrering tillämpas eller inte (markerat med ett [X]` bredvid migreringsnamnet). För en ``--verbosity på 2 och högre visas även de tillämpade datatiderna.

Appar utan migreringar listas också, men har (inga migreringar) skrivet under sig.

Detta är standardutmatningsformatet.

--plan, -p

Visar den migreringsplan som Django kommer att följa för att tillämpa migreringar. Liksom --list markeras tillämpade migreringar med en [X]. För en --verbosity på 2 och högre kommer alla beroenden av en migrering också att visas.

app_label argumenten begränsar utdata, men beroenden av tillhandahållna appar kan också inkluderas.

--database DATABASE

Anger vilken databas som ska undersökas. Standardvärdet är default.

sqlflush

django-admin sqlflush

Skriver ut de SQL-satser som skulle utföras för kommandot flush.

--database DATABASE

Anger den databas för vilken SQL ska skrivas ut. Standardvärdet är default.

`sqlmigrate

django-admin sqlmigrate app_label migration_name

Skriver ut SQL för den namngivna migreringen. Detta kräver en aktiv databasanslutning, som används för att lösa begränsningsnamn. Detta innebär att du måste generera SQL mot en kopia av den databas som du senare vill använda den på.

Observera att sqlmigrate inte färglägger sin utdata.

--backwards

Genererar SQL för att ta bort tillämpningen av migreringen. Som standard skapas SQL för att köra migreringen i framåtriktad riktning.

--database DATABASE

Anger den databas för vilken SQL ska genereras. Standardvärdet är default.

`sqlsekvensuppsättning

django-admin sqlsequencereset app_label [app_label ...]

Skriver ut SQL-satserna för återställning av sekvenser för det eller de angivna appnamnen.

Sekvenser är index som används av vissa databasmotorer för att spåra nästa tillgängliga nummer för automatiskt inkrementerade fält.

Använd detta kommando för att generera SQL som åtgärdar fall där en sekvens inte är synkroniserad med sina automatiskt inkrementerade fältdata.

--database DATABASE

Anger den databas för vilken SQL ska skrivas ut. Standardvärdet är default.

kvashmigreringar

django-admin squashmigrations app_label [start_migration_name] migration_name

Pressar om möjligt ner migreringarna för app_label till och med migration_name till färre migreringar. De resulterande krossade migreringarna kan leva tillsammans med de okrossade på ett säkert sätt. För mer information, läs Minska antalet migreringar.

När start_migration_name anges kommer Django endast att inkludera migreringar som börjar från och med denna migrering. Detta hjälper till att mildra squashing-begränsningen av RunPython och django.db.migrations.operations.RunSQL migreringsoperationer.

--no-optimize

Inaktiverar optimeraren när du genererar en krossad migrering. Som standard kommer Django att försöka optimera operationerna i dina migreringar för att minska storleken på den resulterande filen. Använd det här alternativet om den här processen misslyckas eller skapar felaktiga migreringar, men skicka också in en Django-buggrapport om beteendet, eftersom optimering är tänkt att vara säker.

--noinput, --no-input

Undertrycker alla användarinstruktioner.

--squashed-name SQUASHED_NAME

Ställer in namnet på den krossade migreringen. Om det utelämnas baseras namnet på den första och den sista migreringen, med _squashed_ däremellan.

--no-header

Generera en komprimerad migreringsfil utan Django-version och tidsstämpelhuvud.

startapp

django-admin startapp name [directory]

Skapar en Django-appkatalogstruktur för det angivna appnamnet i den aktuella katalogen eller den angivna destinationen.

Som standard innehåller den nya katalogen en fil models.py och andra appmallfiler. Om endast appnamnet anges kommer appkatalogen att skapas i den aktuella arbetskatalogen.

Om den valfria destinationen anges kommer Django att använda den befintliga katalogen i stället för att skapa en ny. Du kan använda ’.’ för att ange den aktuella arbetskatalogen.

Till exempel:

django-admin startapp myapp /Users/jezdez/Code/myapp

--template TEMPLATE

Anger sökvägen till en katalog med en anpassad appmallfil, eller en sökväg till ett okomprimerat arkiv (.tar) eller ett komprimerat arkiv (.tar.gz, .tar.bz2, .tar.xz, .tar.lzma, .tgz, .tbz2, .txz, .tlz, .zip) som innehåller appmallfilerna.

Exempelvis skulle detta söka efter en appmall i den angivna katalogen när appen myapp skapas:

django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp

Django accepterar också webbadresser (http, https, ftp) till komprimerade arkiv med appmallfilerna och laddar ner och extraherar dem i farten.

Om du till exempel utnyttjar GitHubs funktion för att exponera repositories som zip-filer kan du använda en URL som:

django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp

--extension EXTENSIONS, -e EXTENSIONS

Anger vilka filnamnstillägg i appmallen som ska återges med mallmotorn. Standardvärdet är py.

--name FILES, -n FILES

Anger vilka filer i appmallen (utöver de som matchar --extension) som ska återges med mallmotorn. Standardvärdet är en tom lista.

--exclude DIRECTORIES, -x DIRECTORIES

Anger vilka kataloger i appmallen som ska uteslutas, utöver .git och __pycache__. Om detta alternativ inte anges kommer kataloger som heter __pycache__ eller börjar med . att uteslutas.

Den :klass:`template context <django.template.Context>` som används för alla matchande filer är:

• Alla alternativ som skickas till kommandot startapp (bland de alternativ som stöds av kommandot)

• app_name – appens namn som skickas till kommandot

• app_directory – den fullständiga sökvägen till den nyskapade appen

• camel_case_app_name – appens namn i camel case-format

• docs_version – version av dokumentationen: 'dev' eller '1.x'

• django_version – versionen av Django, t.ex. '2.0.3'`

Varning

När appens mallfiler renderas med Djangos mallmotor (som standard alla *.py-filer), kommer Django också att ersätta alla mallvariabler som finns. Om till exempel en av Python-filerna innehåller en docstring som förklarar en viss funktion relaterad till mallrendering, kan det resultera i ett felaktigt exempel.

För att komma runt detta problem kan du använda templatetag malltaggen för att ”undkomma” de olika delarna av mallsyntaxen.

För att tillåta Python-mallfiler som innehåller syntax för Djangos mallspråk och samtidigt förhindra att paketeringssystem försöker bytekompilera ogiltiga *.py-filer, kommer mallfiler som slutar med .py-tpl att döpas om till .py.

Varning

Innehållet i anpassade app- (eller projekt-) mallar bör alltid granskas före användning: Sådana mallar definierar kod som kommer att bli en del av ditt projekt, och det innebär att sådan kod kommer att vara lika betrodd som alla appar som du installerar eller kod som du skriver själv. Dessutom innebär även rendering av mallarna i praktiken att man exekverar kod som tillhandahölls som indata till hanteringskommandot. Djangos mallspråk kan ge bred tillgång till systemet, så se till att alla anpassade mallar du använder är värda ditt förtroende.

starta projekt

django-admin startproject name [directory]

Skapar en Django-projektkatalogstruktur för det angivna projektnamnet i den aktuella katalogen eller den angivna destinationen.

Som standard innehåller den nya katalogen <django/conf/project_template>` manage.py och ett projektpaket (som innehåller en settings.py och andra filer).

Om endast projektnamnet anges kommer både projektkatalogen och projektpaketet att få namnet <projectname> och projektkatalogen kommer att skapas i den aktuella arbetskatalogen.

Om den valfria destinationen anges kommer Django att använda den befintliga katalogen som projektkatalog och skapa manage.py och projektpaketet i den. Använd ’.’ för att ange den aktuella arbetskatalogen.

Till exempel:

django-admin startproject myproject /Users/jezdez/Code/myproject_repo

--template TEMPLATE

Anger en katalog, filsökväg eller URL för en anpassad projektmall. Se startapp --template-dokumentationen för exempel och användning.

--extension EXTENSIONS, -e EXTENSIONS

Anger vilka filnamnstillägg i projektmallen som ska återges med mallmotorn. Standardvärdet är py.

--name FILES, -n FILES

Anger vilka filer i projektmallen (utöver de som matchar --extension) som ska återges med mallmotorn. Standardvärdet är en tom lista.

--exclude DIRECTORIES, -x DIRECTORIES

Anger vilka kataloger i projektmallen som ska uteslutas, utöver .git och __pycache__. Om det här alternativet inte anges kommer kataloger som heter __pycache__ eller börjar med . att uteslutas.

Den :klass:``template context <django.template.Context>` som används är:

• Alla alternativ som skickas till kommandot startproject (bland de alternativ som stöds av kommandot)

• project_name – projektnamnet som skickas till kommandot

• project_directory – den fullständiga sökvägen till det nyskapade projektet

• secret_key – en slumpmässig nyckel för inställningen :setting:`SECRET_KEY

• docs_version – version av dokumentationen: 'dev' eller '1.x'

• django_version – versionen av Django, t.ex. '2.0.3'`

Se även rendering warning och trusted code warning som nämns för startapp.

test

django-admin test [test_label [test_label ...]]

Kör tester för alla installerade appar. Se Testning i Django för mer information.

--failfast

Stoppar testkörningen och rapporterar felet omedelbart efter att ett test misslyckats.

--testrunner TESTRUNNER

Styr den testkörningsklass som används för att köra tester. Detta värde åsidosätter det värde som anges av inställningen TEST_RUNNER.

--noinput, --no-input

Undertrycker alla uppmaningar till användaren. En typisk uppmaning är en varning om att ta bort en befintlig testdatabas.

Alternativ för testkörning

Kommandot test tar emot alternativ på uppdrag av det angivna --testrunner. Detta är alternativen för standardtestlöparen: DiscoverRunner.

--keepdb

Bevarar testdatabasen mellan testkörningar. Fördelen med detta är att man hoppar över både skapande och förstörande åtgärder, vilket kan minska tiden för testkörning avsevärt, särskilt i en stor testsvit. Om testdatabasen inte finns kommer den att skapas vid den första körningen och sedan bevaras för varje efterföljande körning. Om inte testinställningen MIGRATE är False, kommer alla oanvända migreringar också att tillämpas på testdatabasen innan testsviten körs.

--shuffle [SEED]

Slumpar ordningen på testerna innan de körs. Detta kan hjälpa till att upptäcka tester som inte är ordentligt isolerade. Den testordning som genereras av detta alternativ är en deterministisk funktion av det heltal som anges. Om inget seed anges väljs ett seed slumpmässigt och skrivs ut på konsolen. För att upprepa en viss testordning, skicka ett frö. Testordningarna som genereras av detta alternativ bevarar Djangos garantier för testordning. De håller också tester grupperade efter testfallsklass.

De blandade ordningarna har också en speciell konsistensegenskap som är användbar när man begränsar isoleringsfrågor. För ett givet frö och när en delmängd av testerna körs kommer den nya ordningen att vara den ursprungliga blandningen begränsad till den mindre uppsättningen. På samma sätt kommer ordningen på de ursprungliga testerna att vara densamma i den nya ordningen när du lägger till tester samtidigt som fröet förblir detsamma.

--reverse, -r

Sorterar testfall i motsatt exekveringsordning. Detta kan hjälpa till vid felsökning av bieffekter av tester som inte är ordentligt isolerade. :ref:Gruppering efter testklass <order-of-tests> bevaras när detta alternativ används. Detta kan användas tillsammans med --shuffle för att vända ordningen för ett visst frö.

--debug-mode

Sätter inställningen DEBUG till True innan tester körs. Detta kan hjälpa till att felsöka testfel.

--debug-sql, -d

Aktiverar SQL logging för misslyckade tester. Om --verbosity är 2, kommer frågor i godkända tester också att matas ut.

--parallel [N]

DJANGO_TEST_PROCESSES

Kör tester i separata parallella processer. Eftersom moderna processorer har flera kärnor gör detta att testerna kan köras betydligt snabbare.

Om du använder --parallel utan ett värde, eller med värdet auto, körs en testprocess per kärna enligt multiprocessing.cpu_count(). Du kan åsidosätta detta genom att ange önskat antal processer, t.ex. --parallel 4, eller genom att ställa in miljövariabeln DJANGO_TEST_PROCESSES.

Django distribuerar testfall - unittest.TestCase subclasses - till subprocesser. Om det finns färre testfallsklasser än konfigurerade processer, kommer Django att minska antalet processer i enlighet med detta.

Varje process får sin egen databas. Du måste se till att olika testfallsklasser inte får tillgång till samma resurser. Exempelvis bör testfallsklasser som använder filsystemet skapa en temporär katalog för eget bruk.

Observera

Om du har testklasser som inte kan köras parallellt kan du använda SerializeMixin för att köra dem sekventiellt. Se Tvinga fram sekventiell körning av testklasser.

Detta alternativ kräver tredjeparts tblib-paketet för att visa spårningar korrekt:

$ python -m pip install tblib

Den här funktionen är inte tillgänglig i Windows. Den fungerar inte heller med Oracle-databasens backend.

Om du vill använda pdb när du felsöker tester måste du inaktivera parallellkörning (--parallel=1). Du kommer att se något i stil med bdb.BdbQuit om du inte gör det.

Varning

När testparallellisering är aktiverad och ett test misslyckas kan Django kanske inte visa spårningen av undantaget. Detta kan göra felsökningen svår. Om du stöter på detta problem, kör det berörda testet utan parallellisering för att se spårningen av felet.

Detta är en känd begränsning. Den uppstår på grund av behovet av att serialisera objekt för att kunna utbyta dem mellan processer. Se What can be pickled and unpickled? för detaljer.

--tag TAGS

Kör endast tester märkta med de angivna taggarna. Kan anges flera gånger och kombineras med test --exclude-tag.

Tester som inte laddas betraktas alltid som matchande.

--exclude-tag EXCLUDE_TAGS

Utesluter tester märkta med de angivna taggarna. Kan anges flera gånger och kombineras med test --tag.

-k TEST_NAME_PATTERNS

Kör testmetoder och klasser som matchar testnamnsmönster, på samma sätt som unittests -k-alternativ. Kan anges flera gånger.

--pdb

Startar en pdb-felsökare vid varje fel eller misslyckande i testet. Om du har det installerat används ipdb istället.

--buffer, -b

Slänger utdata (stdout och stderr) för godkända tester, på samma sätt som unittests alternativ --buffer.

--no-faulthandler

Django anropar automatiskt faulthandler.enable() när testerna startas, vilket gör det möjligt att skriva ut en spårning om tolken kraschar. Passera --no-faulthandler för att inaktivera detta beteende.

--timing

Utmatning av tidsangivelser, inklusive databasinstallation och total körtid.

--durations N

Visar de N långsammaste testfallen (N=0 för alla).

Python 3.12 eller senare

Denna funktion är endast tillgänglig för Python 3.12 och senare.

testserver

django-admin testserver [fixture [fixture ...]]

Kör en Django-utvecklingsserver (som i runserver) med data från den eller de angivna fixturerna.

Till exempel: detta kommando:

django-admin testserver mydata.json

…skulle utföra följande steg:

1. Skapa en testdatabas, enligt beskrivningen i testdatabasen.

2. Fyller på testdatabasen med fixturdata från de angivna fixturerna. (För mer information om fixturer, se dokumentationen för loaddata ovan)

3. Kör Django-utvecklingsservern (som i runserver), riktad mot denna nyskapade testdatabas i stället för din produktionsdatabas.

Detta är användbart på flera olika sätt:

• När du skriver enhetstester av hur dina vyer fungerar med vissa fixturdata, kan du använda testserver för att interagera med vyerna i en webbläsare, manuellt.

• Låt oss säga att du utvecklar din Django-applikation och har en ”orörd” kopia av en databas som du skulle vilja interagera med. Du kan dumpa din databas till en fixture (med kommandot dumpdata, som förklaras ovan) och sedan använda testserver för att köra din webbapplikation med dessa data. Med det här arrangemanget har du flexibiliteten att röra till dina data på något sätt och veta att alla dataändringar du gör bara görs till en testdatabas.

Observera att den här servern inte automatiskt upptäcker ändringar i din Python-källkod (som runserver gör). Den upptäcker dock ändringar i mallar.

--addrport ADDRPORT

Anger en annan port, eller IP-adress och port, än standardvärdet 127.0.0.1:8000. Detta värde följer exakt samma format och har exakt samma funktion som argumentet till kommandot runserver.

Exempel:

För att köra testservern på port 7000 med fixture1 och fixture2:

django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000

(Ovanstående uttalanden är likvärdiga. Vi tar med båda för att visa att det inte spelar någon roll om alternativen kommer före eller efter fixturargumenten)

För att köra på 1.2.3.4:7000 med en test fixtur:

django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input

Undertrycker alla uppmaningar till användaren. En typisk uppmaning är en varning om att ta bort en befintlig testdatabas.

Kommandon som tillhandahålls av applikationer

Vissa kommandon är endast tillgängliga när applikationen django.contrib som implementerar dem har aktiverats. Detta avsnitt beskriver dem grupperade efter deras applikation.

django.contrib.auth

byt lösenord

django-admin changepassword [<username>]

Detta kommando är endast tillgängligt om Djangos autentiseringssystem (django.contrib.auth) är installerat.

Gör det möjligt att ändra en användares lösenord. Du uppmanas att ange ett nytt lösenord två gånger för den aktuella användaren. Om inmatningarna är identiska blir detta omedelbart det nya lösenordet. Om du inte anger någon användare kommer kommandot att försöka ändra lösenordet för den användare vars användarnamn matchar den aktuella användaren.

--database DATABASE

Anger vilken databas som ska användas för att söka efter användaren. Standardvärdet är default.

Exempel på användning:

django-admin changepassword ringo

skapa superanvändare

django-admin createsuperuser

DJANGO_SUPERUSER_PASSWORD

Detta kommando är endast tillgängligt om Djangos autentiseringssystem (django.contrib.auth) är installerat.

Skapar ett superanvändarkonto (en användare som har alla behörigheter). Detta är användbart om du behöver skapa ett första superanvändarkonto eller om du behöver generera superanvändarkonton för dina webbplatser på ett programmatiskt sätt.

När kommandot körs interaktivt kommer det att fråga efter ett lösenord för det nya superanvändarkontot. När kommandot körs icke-interaktivt kan du ange ett lösenord genom att ange miljövariabeln DJANGO_SUPERUSER_PASSWORD. Annars anges inget lösenord och superanvändarkontot kan inte logga in förrän ett lösenord har angetts manuellt för det.

I icke-interaktivt läge faller USERNAME_FIELD och obligatoriska fält (listade i REQUIRED_FIELDS) tillbaka till miljövariablerna DJANGO_SUPERUSER_<uppercase_field_name>, såvida de inte åsidosätts av ett kommandoradsargument. Om du t.ex. vill tillhandahålla ett fält för e-post kan du använda miljövariabeln DJANGO_SUPERUSER_EMAIL.

--noinput, --no-input

Undertrycker alla användarinstruktioner. Om en undertryckt fråga inte kan lösas automatiskt avslutas kommandot med felkod 1.

--username USERNAME

--email EMAIL

Användarnamnet och e-postadressen för det nya kontot kan anges med argumenten --username och --email på kommandoraden. Om något av dessa inte anges kommer createsuperuser att fråga efter det när det körs interaktivt.

--database DATABASE

Anger den databas i vilken superuser-objektet ska sparas.

Du kan underklassa management-kommandot och åsidosätta get_input_data() om du vill anpassa datainmatning och validering. I källkoden finns mer information om den befintliga implementeringen och metodens parametrar. Det kan till exempel vara användbart om du har en ForeignKey i REQUIRED_FIELDS och vill tillåta att en instans skapas istället för att ange primärnyckeln för en befintlig instans.

django.contrib.contenttypes

ta bort_stale_innehållstyper

django-admin remove_stale_contenttypes

Detta kommando är endast tillgängligt om Djangos contenttypes app (django.contrib.contenttypes) är installerat.

Raderar inaktuella innehållstyper (från borttagna modeller) i din databas. Alla objekt som är beroende av de borttagna innehållstyperna kommer också att raderas. En lista över borttagna objekt visas innan du bekräftar att det är okej att fortsätta med borttagningen.

--database DATABASE

Anger vilken databas som ska användas. Standardvärdet är default.

--include-stale-apps

Raderar inaktuella innehållstyper, inklusive innehåll från tidigare installerade appar som har tagits bort från INSTALLED_APPS. Standardvärde är False.

django.contrib.gis

ogrinspect

Detta kommando är endast tillgängligt om GeoDjango (django.contrib.gis) är installerat.

Se dess description i GeoDjango-dokumentationen.

django.contrib.sessions

clearsessions

django-admin clearsessions

Kan köras som ett cron-jobb eller direkt för att rensa bort utgångna sessioner.

django.contrib.staticfiles

samla statiskt

Detta kommando är endast tillgängligt om applikationen för statiska filer (django.contrib.staticfiles) är installerad.

Se dess description i staticfiles dokumentation.

findstatic

Detta kommando är endast tillgängligt om applikationen för statiska filer (django.contrib.staticfiles) är installerad.

Se dess description i staticfiles dokumentation.

Standardalternativ

Även om vissa kommandon kan tillåta egna anpassade alternativ, tillåter alla kommandon följande alternativ som standard:

--pythonpath PYTHONPATH

Lägger till den angivna filsystemssökvägen till Python sys.path-modulattributet. Om detta inte anges kommer django-admin att använda miljövariabeln PYTHONPATH.

Detta alternativ är onödigt i manage.py, eftersom det tar hand om att ställa in Python-sökvägen åt dig.

Exempel på användning:

django-admin migrate --pythonpath='/home/djangoprojects/myproject'

--settings SETTINGS

Anger vilken inställningsmodul som ska användas. Inställningsmodulen bör vara i Python-paketsyntax, t.ex. mysite.settings. Om detta inte anges kommer django-admin att använda miljövariabeln DJANGO_SETTINGS_MODULE.

Detta alternativ är onödigt i manage.py, eftersom det använder settings.py från det aktuella projektet som standard.

Exempel på användning:

django-admin migrate --settings=mysite.settings

--traceback

Visar en fullständig stackspårning när ett CommandError uppstår. Som standard kommer django-admin att visa ett felmeddelande när ett CommandError inträffar och en fullständig stack trace för alla andra undantag.

Detta alternativ ignoreras av runserver.

Exempel på användning:

django-admin migrate --traceback

--verbosity {0,1,2,3}, -v {0,1,2,3}

Anger hur mycket meddelande- och felsökningsinformation som ett kommando ska skriva ut till konsolen.

• 0 betyder ingen utmatning.

• 1 betyder normal utmatning (standard).

• 2 betyder utförlig utdata.

• 3 betyder mycket utförlig utdata.

Detta alternativ ignoreras av runserver.

Exempel på användning:

django-admin migrate --verbosity 2

--no-color

Inaktiverar färgad kommandoutmatning. Vissa kommandon formaterar sina utdata så att de blir färgade. Exempelvis skrivs fel ut till konsolen i rött och SQL-satser syntaxmarkeras.

Exempel på användning:

django-admin runserver --no-color

--force-color

Tvingar fram färgläggning av kommandoutmatningen om den annars skulle vara inaktiverad, vilket diskuteras i Syntax färgläggning. Du kanske t.ex. vill skicka färgade utdata till ett annat kommando.

--skip-checks

Hoppar över att köra systemkontroller innan kommandot körs. Detta alternativ är endast tillgängligt om requires_system_checks inte är en tom lista eller tupel.

Exempel på användning:

django-admin migrate --skip-checks

Extra finesser

Syntax färgläggning

DJANGO_COLORS

Kommandona django-admin / manage.py kommer att använda vackra färgkodade utdata om din terminal stöder ANSI-färgade utdata. Det kommer inte att använda färgkoderna om du skickar kommandots utdata till ett annat program om inte alternativet --force-color används.

Stöd för Windows

I Windows 10 tillåter programmet Windows Terminal, VS Code och PowerShell (där bearbetning i virtuell terminal är aktiverad) färgad utdata och stöds som standard.

Under Windows stöder inte den gamla inbyggda konsolen cmd.exe ANSI escape-sekvenser, så som standard finns det ingen färgutmatning. I detta fall behövs något av de två tredjepartsbiblioteken:

• Installera colorama, ett Python-paket som översätter ANSI-färgkoder till Windows API-anrop. Django-kommandon kommer att upptäcka dess närvaro och använda dess tjänster för att färglägga utdata precis som på Unix-baserade plattformar. colorama kan installeras via pip:

  ...\> py -m pip install "colorama >= 0.4.6"
  

• Installera ANSICON, ett tredjepartsverktyg som gör det möjligt för cmd.exe att bearbeta ANSI-färgkoder. Django-kommandon kommer att upptäcka dess närvaro och använda dess tjänster för att färglägga utdata precis som på Unix-baserade plattformar.

Andra moderna terminalmiljöer på Windows, som stöder terminalfärger, men som inte automatiskt upptäcks som stödda av Django, kan ”fejka” installationen av ANSICON genom att ställa in lämplig miljövariabel, ANSICON="on".

Anpassade färger

De färger som används för syntaxmarkering kan anpassas. Django levereras med tre färgpaletter:

• dark, lämplig för terminaler som visar vit text på svart bakgrund. Detta är standardpaletten.

• light, lämpar sig för terminaler som visar svart text på vit bakgrund.

• nocolor, som inaktiverar syntaxmarkering.

Du väljer en palett genom att ange en DJANGO_COLORS-miljövariabel som anger vilken palett du vill använda. Om du till exempel vill ange paletten light i ett Unix- eller OS/X BASH-skal, kör du följande vid kommandotolken:

export DJANGO_COLORS="light"

Du kan också anpassa de färger som används. Django specificerar ett antal roller där färg används:

• error - Ett allvarligt fel.

• notice - Ett mindre fel.

• uccess - En framgång.

• warning - En varning.

• sql_field - Namnet på ett modellfält i SQL.

• sql_coltype - Typen av ett modellfält i SQL.

• sql_keyword - Ett SQL-nyckelord.

• sql_table - Namnet på en modell i SQL.

• http_info - Ett 1XX HTTP-informationssvar från servern.

• http_success - Ett 2XX HTTP Success-serversvar.

• http_not_modified - Ett 304 HTTP Not Modified-serversvar.

• http_redirect - Ett 3XX HTTP Redirect-serversvar annat än 304.

• http_not_found - Ett 404 HTTP Not Found-serversvar.

• http_bad_request - Ett 4XX HTTP Bad Request-serversvar annat än 404.

• http_server_error - Ett 5XX HTTP Server Error-svar.

• migrate_heading - En rubrik i ett kommando för migrationshantering.

• migrate_label - Ett namn på migreringen.

Var och en av dessa roller kan tilldelas en specifik förgrunds- och bakgrundsfärg från följande lista:

• svart

• ”röd

• grön

• gult

• blått

• magenta

• cyan

• vit

Var och en av dessa färger kan sedan ändras med hjälp av följande visningsalternativ:

• fett

• underscore

• blink

• omvänd

• ”dölja

En färgspecifikation följer något av följande mönster:

• role=fg

• role=fg/bg

• roll=fg,option,option

• roll=fg/bg,option,option

där role är namnet på en giltig färgroll, fg är förgrundsfärgen, bg är bakgrundsfärgen och varje option är ett av färgmodifieringsalternativen. Flera färgspecifikationer separeras sedan med ett semikolon. Till exempel:

export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

skulle ange att fel visas med blinkande gult på blått och meddelanden visas med magenta. Alla andra färgroller skulle lämnas ofärgade.

Färger kan också specificeras genom att utöka en baspalett. Om du anger ett palettnamn i en färgspecifikation laddas alla färger som impliceras av den paletten. Så här gör du:

export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

skulle ange användningen av alla färger i den ljusa färgpaletten, utom färgerna för fel och meddelanden som skulle åsidosättas enligt specifikationen.

Bash-avslutning

Om du använder Bash-skalet, överväg att installera Django bash-kompletteringsscriptet, som finns i extras/django_bash_completion i Django-källdistributionen. Det möjliggör tabkomplettering av kommandon i django-admin och manage.py, så att du till exempel kan …

• Typ django-admin.

• Tryck på [TAB] för att se alla tillgängliga alternativ.

• Skriv sql och sedan [TAB] för att se alla tillgängliga alternativ vars namn börjar med sql.

Se Hur man skapar egna kommandon för django-admin för information om hur du lägger till anpassade åtgärder.

Svart formatering

Python-filerna som skapas av startproject, startapp, optimizemigration, makemigrations och squashmigrations formateras med kommandot black om det finns i din PATH.

Om du har black globalt installerat, men inte vill att det ska användas för det aktuella projektet, kan du ange PATH explicit:

PATH=path/to/venv/bin django-admin makemigrations

För kommandon som använder stdout kan du vid behov skicka utdata till black:

django-admin inspectdb | black -

Kör kommandon för hantering från din kod

django.core.management.call_command(name, *args, **options)

Om du vill anropa ett managementkommando från kod använder du call_command().

namn

namnet på kommandot som ska anropas eller ett kommando-objekt. Att skicka namnet är att föredra om inte objektet krävs för testning.

*args

en lista med argument som accepteras av kommandot. Argumenten skickas till argumentparsern, så att du kan använda samma stil som på kommandoraden. Till exempel:, call_command('flush', '--verbosity=0').

**alternativ

namngivna alternativ som accepteras på kommandoraden. Alternativen skickas till kommandot utan att argumentparsern aktiveras, vilket innebär att du måste skicka rätt typ. Till exempel:, call_command('flush', verbosity=0) (noll måste vara ett heltal snarare än en sträng).

Exempel:

from django.core import management
from django.core.management.commands import loaddata

management.call_command("flush", verbosity=0, interactive=False)
management.call_command("loaddata", "test_data", verbosity=0)
management.call_command(loaddata.Command(), "test_data", verbosity=0)

Observera att kommandoval som inte tar några argument skickas som nyckelord med True eller False, som du kan se med alternativet interactive ovan.

Namngivna argument kan skickas genom att använda någon av följande syntaxer:

# Similar to the command line
management.call_command("dumpdata", "--natural-foreign")

# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command("dumpdata", natural_foreign=True)

# `use_natural_foreign_keys` is the option destination variable
management.call_command("dumpdata", use_natural_foreign_keys=True)

Vissa kommandoalternativ har olika namn när du använder call_command() istället för django-admin eller manage.py. Till exempel: översätts django-admin createsuperuser --no-input till call_command('createsuperuser', interactive=False). För att hitta vilket nyckelordsargumentnamn som ska användas för call_command(), kontrollera kommandots källkod för dest-argumentet som skickas till parser.add_argument().

Kommandoval som innehåller flera alternativ skickas till en lista:

management.call_command("dumpdata", exclude=["contenttypes", "auth"])

Returvärdet för funktionen call_command() är detsamma som returvärdet för kommandots metod handle().

Omdirigering av utdata

Observera att du kan omdirigera standardutdata- och felströmmar eftersom alla kommandon stöder alternativen stdout och stderr. Du kan till exempel skriva:

with open("/path/to/command_output", "w") as f:
    management.call_command("dumpdata", stdout=f)