django-admin – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

django-admin - Dienstprogrammskript für das Django Web-Framework

django-admin ist Djangos Befehlszeilen-Dienstprogramm für Verwaltungsaufgaben. Dieses Dokument
beschreibt alles, was es tun kann.

Vor Django 1.7, django-admin wurde nur als installiert django-admin.py.

Zudem hat auch Frau manage.py wird automatisch in jedem Django-Projekt erstellt. manage.py ist eine
dünne Hülle rundherum django-admin Das erledigt im Vorfeld mehrere Dinge für Sie
delegieren an django-admin:

· Es legt das Paket Ihres Projekts an sys.pfad.

· Es legt fest DJANGO_SETTINGS_MODULE Umgebungsvariable so, dass sie auf Ihre zeigt
Projekte settings.py Datei.

· Es ruft django.setup() um verschiedene Interna von Django zu initialisieren.

django.setup() existierte in früheren Versionen von Django nicht.

Die django-admin Das Skript sollte sich in Ihrem Systempfad befinden, wenn Sie Django darüber installiert haben
setup.py Dienstprogramm. Wenn es nicht auf Ihrem Weg ist, können Sie es in finden site-packages/django/bin
innerhalb Ihrer Python-Installation. Erwägen Sie, es von einer Stelle auf Ihrem Weg aus zu verknüpfen, z
as / usr / local / bin.

Für Windows-Benutzer, die keine Symlinking-Funktionalität zur Verfügung haben, können Sie kopieren
django-admin.exe zu einer Position auf Ihrem vorhandenen Pfad oder bearbeiten Sie die PATH Einstellungen (unter
Einstellungen - Kontrollieren Tafel - System - Erweitert - Umfeld...), um auf die Installation hinzuweisen


Wenn Sie an einem einzelnen Django-Projekt arbeiten, ist die Verwendung im Allgemeinen einfacher manage.py als
django-admin. Wenn Sie zwischen mehreren Django-Einstellungsdateien wechseln müssen, verwenden Sie
django-admin mit DJANGO_SETTINGS_MODULE oder unter der --die Einstellungen Befehlszeilenoption.

Die Befehlszeilenbeispiele in diesem Dokument verwenden django-admin um konsequent zu sein, aber
Jedes Beispiel kann verwendet werden manage.py genausogut.

ANWENDUNG

$ django-admin [Optionen]
$ manage.py [Optionen]

Befehl sollte einer der in diesem Dokument aufgeführten Befehle sein. Optionen, Das ist
optional, sollte null oder mehr der für den angegebenen Befehl verfügbaren Optionen sein.

Ihre ersten Laufzeit Hilfe
django-admin Hilfe

Führen Sie django-admin Hilfe um Nutzungsinformationen und eine Liste der von bereitgestellten Befehle anzuzeigen
jede Anwendung.

Führen Sie django-admin Hilfe --Befehle um eine Liste aller verfügbaren Befehle anzuzeigen.

Führen Sie django-admin Hilfe um eine Beschreibung des angegebenen Befehls und eine Liste anzuzeigen
seiner verfügbaren Optionen.

App Namen
Viele Befehle benötigen eine Liste von „App-Namen“. Ein „App-Name“ ist der Basisname des Pakets
enthält Ihre Modelle. Zum Beispiel, wenn Ihr INSTALLED_APPS enthält die Zeichenfolge
'meinesite.blog', der App-Name ist Blog.

Festlegung die Version
django-admin Version

Führen Sie django-admin Version um die aktuelle Django-Version anzuzeigen.

Die Ausgabe folgt dem in beschriebenen Schema PEP 386:

1.4.dev17026
1.4a1
1.4

Zeige debuggen Möglichkeiten für das Ausgangssignal:
Nutzen Sie --ausführlich um die Menge der Benachrichtigungs- und Debug-Informationen anzugeben
django-admin sollte auf der Konsole gedruckt werden. Weitere Einzelheiten finden Sie in der Dokumentation zum
--ausführlich .

VERFÜGBAR BEFEHLE

aus der Ferne überprüfen <Appname App Name ...>
django-admin aus der Ferne überprüfen

verwendet die fragst aus der Ferne überprüfen Rahmen um das gesamte Django-Projekt auf häufige Probleme zu untersuchen.

Das Systemüberprüfungs-Framework bestätigt, dass bei Ihrer Installation keine Probleme vorliegen
Modelle oder Ihre Admin-Registrierungen. Es werden auch Warnungen zur allgemeinen Kompatibilität angezeigt
Probleme, die durch das Upgrade von Django auf eine neue Version entstanden sind. Es können kundenspezifische Schecks eingeführt werden
von anderen Bibliotheken und Anwendungen.

Standardmäßig werden alle Apps überprüft. Sie können eine Teilmenge der Apps überprüfen, indem Sie eine Liste bereitstellen
von App-Labels als Argumente:

Python manage.py auth. admin myapp prüfen

Wenn Sie keine App angeben, werden alle Apps überprüft.

--Schild

Die fragst aus der Ferne überprüfen Rahmen führt viele verschiedene Arten von Kontrollen durch. Diese Schecktypen sind
mit Tags kategorisiert. Mithilfe dieser Tags können Sie die durchgeführten Prüfungen auf Folgendes beschränken
diejenigen in einer bestimmten Kategorie. Beispielsweise, um nur Sicherheit und Kompatibilität zu gewährleisten
prüft, würden Sie Folgendes ausführen:

Python manage.py prüft die Kompatibilität von --tag security --tag

--list-tags

Listen Sie alle verfügbaren Tags auf.

--einsetzen

Die --einsetzen Die Option aktiviert einige zusätzliche Prüfungen, die nur in a relevant sind
Bereitstellungseinstellung.

Sie können diese Option in Ihrer lokalen Entwicklungsumgebung verwenden, aber da Ihre lokale
Das Entwicklungseinstellungsmodul verfügt möglicherweise nicht über viele Ihrer Produktionseinstellungen
Ich möchte wahrscheinlich darauf hinweisen aus der Ferne überprüfen Befehl in einem anderen Einstellungsmodul, entweder durch Einstellung
die DJANGO_SETTINGS_MODULE Umgebungsvariable oder durch Übergabe der --die Einstellungen Option:

Python manage.py check --deploy --settings=produktionseinstellungen

Oder Sie können es direkt in einer Produktions- oder Staging-Bereitstellung ausführen, um zu überprüfen, ob
Es werden die richtigen Einstellungen verwendet (weglassen). --die Einstellungen). Sie könnten es sogar zu einem Teil Ihres machen
Integrationstestsuite.

Nachrichten kompilieren
django-admin Nachrichten kompilieren

Kompiliert von erstellte .po-Dateien Nachrichten machen in .mo-Dateien zur Verwendung mit dem integrierten Gettext
Unterstützung. Sehen /topics/i18n/index.

Verwenden Sie das - Gebietsschema Option (oder ihre kürzere Version). -l), um die zu verarbeitenden Gebietsschema(s) anzugeben.
Wenn nicht angegeben, werden alle Gebietsschemas verarbeitet.

Verwenden Sie das --ausschließen Option (oder ihre kürzere Version). -x), um die auszuschließenden Gebietsschema(s) anzugeben
aus der Verarbeitung. Wenn nicht angegeben, werden keine Gebietsschemas ausgeschlossen.

Sie können durch --use-fuzzy Option (oder -f), um Fuzzy-Übersetzungen in kompilierte Dateien einzubinden.

Hinzugefügt --ausschließen und --use-fuzzy nach.

Beispielverwendung:

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

Cache-Datei erstellen
django-admin Cache-Datei erstellen

Erstellt die Cache-Tabellen zur Verwendung mit dem Datenbank-Cache-Backend. Sehen /topics/cache für
mehr Informationen.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, in der die Cachetabelle gespeichert werden soll
installiert werden.

Es ist nicht mehr erforderlich, den Namen der Cache-Tabelle oder den Namen anzugeben --Datenbank Möglichkeit. Django
übernimmt diese Informationen aus Ihrer Einstellungsdatei. Wenn Sie mehrere Caches konfiguriert haben oder
Bei mehreren Datenbanken werden alle Cache-Tabellen erstellt.

dbshell
django-admin dbshell

Führt den Befehlszeilen-Client für die in Ihrem angegebene Datenbank-Engine aus ENGINE Rahmen,
mit den in Ihrem angegebenen Verbindungsparametern USER, PASSWORDusw., Einstellungen.

· Für PostgreSQL führt dies aus psql Befehlszeilen-Client.

· Für MySQL führt dies aus mysql Befehlszeilen-Client.

· Für SQLite führt dies aus sqlite3 Befehlszeilen-Client.

Bei diesem Befehl wird davon ausgegangen, dass sich die Programme auf Ihrem Computer befinden PATH so dass ein einfacher Aufruf des Programms
Name (psql, mysql, sqlite3) finden Sie das Programm an der richtigen Stelle. Es gibt keine Möglichkeit dazu
Geben Sie den Speicherort des Programms manuell an.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, in der eine Shell geöffnet werden soll.

Differenzeinstellungen
django-admin Differenzeinstellungen

Zeigt Unterschiede zwischen der aktuellen Einstellungsdatei und den Standardeinstellungen von Django an.

Auf Einstellungen, die nicht in den Standardeinstellungen enthalten sind, folgt „ "###". Zum Beispiel die Standardeinstellung
Einstellungen definieren nicht ROOT_URLCONF, damit ROOT_URLCONF wird gefolgt von "###" in der Ausgabe von
Differenzeinstellungen.

Die --alle Möglicherweise wird die Option bereitgestellt, alle Einstellungen anzuzeigen, auch wenn diese über Djangos verfügen
Standardwert. Solche Einstellungen werden durch vorangestellt "###".

Dumpdaten <app_label app_label app_label.Model ...>
django-admin Dumpdaten

Gibt alle Daten in der Datenbank, die mit dem benannten verbunden sind, auf die Standardausgabe aus
Anwendung(en).

Wenn kein Anwendungsname angegeben wird, werden alle installierten Anwendungen gelöscht.

Die Ausgabe von Dumpdaten kann als Eingabe für verwendet werden lade Daten.

Beachten Sie, dass Dumpdaten Verwendet den Standardmanager im Modell für die Auswahl der Datensätze
entsorgen. Wenn Sie a verwenden Original Manager als Standardmanager und filtert einige davon
Aufgrund der verfügbaren Datensätze werden nicht alle Objekte gedumpt.

Die --alle Es kann eine Option bereitgestellt werden, um dies anzugeben Dumpdaten sollte Djangos Basis verwenden
Manager, der Datensätze ausgibt, die andernfalls von einem Benutzer gefiltert oder geändert werden könnten
Manager.

--Format

Standardmäßig Dumpdaten formatiert seine Ausgabe in JSON, Sie können jedoch die verwenden --Format ganz ohne irgendetwas tun oder drücken zu müssen.
um ein anderes Format anzugeben. Derzeit unterstützte Formate sind in aufgeführt
Serialisierungsformate.

--Einzug

Standardmäßig Dumpdaten gibt alle Daten in einer einzigen Zeile aus. Das ist für den Menschen nicht einfach
lesen, damit Sie das nutzen können --Einzug Option zum hübschen Drucken der Ausgabe mit einer Reihe von
Einrückungsräume.

Die --ausschließen Es kann eine Option bereitgestellt werden, um bestimmte Anwendungen oder Modelle zu verhindern (spezifiziert).
wie in der Form von app_label.ModelName) vor der Entsorgung. Wenn Sie einen Modellnamen angeben, um
Dumpdaten, wird die ausgegebene Ausgabe auf dieses Modell und nicht auf das gesamte Modell beschränkt
Anwendung. Sie können auch Anwendungsnamen und Modellnamen mischen.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, aus der Daten ausgegeben werden.

--natürlich-fremd

Wenn diese Option angegeben ist, verwendet Django die natural_key() Modellmethode zum Serialisieren
Jeder Fremdschlüssel und eine Viele-zu-Viele-Beziehung zu Objekten des Typs, der den definiert
Methode. Wenn Sie entsorgen Beitrag.auth Genehmigung Gegenstände oder contrib.contenttypes
Inhaltstyp Objekte, sollten Sie wahrscheinlich dieses Flag verwenden. Siehe die natürlich Tasten
Weitere Informationen zu dieser und der nächsten Option finden Sie in der Dokumentation.

--natural-primär

Wenn diese Option angegeben ist, stellt Django den Primärschlüssel nicht in der serialisierten Datei bereit
Daten dieses Objekts, da sie während der Deserialisierung berechnet werden können.

--natürlich

Veraltet seit Version 1.7: Entspricht dem --natürlich-fremd Möglichkeit; verwende das
stattdessen.

Nutzen Sie natürlich Tasten um einen beliebigen Fremdschlüssel und eine Viele-zu-Viele-Beziehung mit einem Modell darzustellen
das liefert eine natürliche Schlüsseldefinition.

--pks

Standardmäßig Dumpdaten gibt alle Datensätze des Modells aus, Sie können jedoch die verwenden --pks
Option zum Angeben einer durch Kommas getrennten Liste von Primärschlüsseln, nach denen gefiltert werden soll. Das ist nur
verfügbar, wenn ein Modell entsorgt wird.

--Ausgabe

Standardmäßig Dumpdaten gibt alle serialisierten Daten an die Standardausgabe aus. Diese Optionen
ermöglicht die Angabe der Datei, in die die Daten geschrieben werden sollen.

spülen
django-admin spülen

Entfernt alle Daten aus der Datenbank, führt alle Handler nach der Synchronisierung erneut aus und
Installiert alle anfänglichen Datenbefestigungen neu.

Die --keine Eingabe Es kann eine Option bereitgestellt werden, um alle Benutzeraufforderungen zu unterdrücken.

Die --Datenbank Die Option kann verwendet werden, um die zu leerende Datenbank anzugeben.

--no-initial-data
Nutzen Sie --no-initial-data um das Laden der initial_data-Fixture zu vermeiden.

inspizierendb
django-admin inspizierendb

Untersucht die Datenbanktabellen und -ansichten in der Datenbank, auf die verwiesen wird NAME/FUNKTION Einstellung
und gibt ein Django-Modellmodul (a modelle.py Datei) in die Standardausgabe.

Verwenden Sie dies, wenn Sie über eine ältere Datenbank verfügen, mit der Sie Django verwenden möchten. Das Drehbuch
prüft die Datenbank und erstellt ein Modell für jede darin enthaltene Tabelle oder Ansicht.

Wie zu erwarten ist, verfügen die erstellten Modelle über ein Attribut für jedes Feld im
Tabelle oder Ansicht. Beachten Sie, dass inspizierendb hat ein paar Sonderfälle in seiner Feldnamenausgabe:

· Wenn inspizierendb Der Typ einer Spalte kann nicht einem Modellfeldtyp zugeordnet werden, der verwendet wird Textfeld und
fügt den Python-Kommentar ein 'Dies Feld tippe is a erraten.' neben dem Feld im
generiertes Modell.

· Wenn der Datenbankspaltenname ein für Python reserviertes Wort ist (z. B 'passieren', 'Klasse' or
'zum'), inspizierendb wird anhängen '_Feld' zum Attributnamen. Zum Beispiel, wenn ein Tisch
hat eine Spalte 'zum', das generierte Modell verfügt über ein Feld 'for_field', Mit dem
db_column Attribut gesetzt auf 'zum'. inspizierendb fügt den Python-Kommentar ein 'Feld
umbenannt weil it wurde a Python reserviert Wort.' neben dem Feld.

Diese Funktion ist als Abkürzung und nicht als endgültige Modellgenerierung gedacht. Nachdem Sie es ausgeführt haben,
Sie sollten sich die generierten Modelle selbst ansehen, um Anpassungen vorzunehmen. In
Insbesondere müssen Sie die Reihenfolge der Modelle ändern, sodass Modelle auf andere verweisen
Die Modelle sind ordnungsgemäß bestellt.

Primärschlüssel werden für PostgreSQL, MySQL und SQLite automatisch überprüft
Fall Django setzt in den Primary_key=True wo benötigt.

inspizierendb funktioniert mit PostgreSQL, MySQL und SQLite. Die Fremdschlüsselerkennung funktioniert nur in
PostgreSQL und mit bestimmten Arten von MySQL-Tabellen.

Django erstellt keine Datenbankstandards, wenn a Standard wird in einem Modellfeld angegeben.
Ebenso werden Datenbankstandards nicht in Modellfeldstandards übersetzt oder darin erkannt
Mode von inspizierendb.

Standardmäßig inspizierendb erstellt nicht verwaltete Modelle. Das ist, verwaltet = falsch im Modell
Meta Die Klasse weist Django an, die Erstellung, Änderung und Löschung jeder Tabelle nicht zu verwalten.
Wenn Sie Django erlauben möchten, den Lebenszyklus der Tabelle zu verwalten, müssen Sie das ändern
verwaltet Option zu richtig (Oder entfernen Sie es einfach, weil richtig ist der Standardwert).

Die --Datenbank Die Option kann verwendet werden, um die Datenbank anzugeben, die überprüft werden soll.

Eine Funktion zum Überprüfen von Datenbankansichten wurde hinzugefügt. In früheren Versionen waren nur Tabellen (nicht
Ansichten) wurden überprüft.

lade Daten <Gerät Befestigung ...>
django-admin lade Daten

Sucht und lädt den Inhalt des benannten Fixtures in die Datenbank.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, in der die Daten gespeichert werden sollen
geladen.

--ignorenonexistent

Die --ignorenonexistent Mit der Option können eventuell vorhandene Felder und Modelle ignoriert werden
entfernt, da das Fixture ursprünglich generiert wurde.

- App

Die - App Mit dieser Option können Sie eine einzelne App angeben, in der nach Fixtures gesucht werden soll
Durchsuchen aller Apps.

- App wurde hinzugefügt.

--ignorenonexistent ignoriert auch nicht vorhandene Modelle.

Was ist a Befestigung ?
A Befestigung ist eine Sammlung von Dateien, die den serialisierten Inhalt der Datenbank enthalten.
Jedes Gerät hat einen eindeutigen Namen und die Dateien, aus denen das Gerät besteht, können verteilt werden
über mehrere Verzeichnisse, in mehreren Anwendungen.

Django sucht an drei Orten nach Spielplänen:

1. In dem Armaturen Verzeichnis jeder installierten Anwendung

2. In einem beliebigen Verzeichnis mit dem Namen FIXTURE_DIRS Einstellung

3. Im vom Gerät benannten Literalpfad

Django lädt alle Fixtures, die es an diesen Orten findet und die mit den bereitgestellten übereinstimmen
Gerätenamen.

Wenn das benannte Gerät eine Dateierweiterung hat, werden nur Geräte dieses Typs geladen. Für
Beispiel:

django-admin lädt Daten mydata.json

würde nur aufgerufene JSON-Geräte laden meine Daten. Die Leuchtenverlängerung muss mit der übereinstimmen
eingetragener Name eines Serializer (z.B, JSON or xml).

Wenn Sie die Erweiterungen weglassen, durchsucht Django alle verfügbaren Fixture-Typen nach einer Übereinstimmung
Vorrichtung. Zum Beispiel:

django-admin lädt Daten meine Daten

würde nach jedem Fixture eines beliebigen Fixture-Typs suchen meine Daten. Wenn ein Fixture-Verzeichnis
enthalten mydata.json, würde dieses Fixture als JSON-Fixture geladen.

Die benannten Fixtures können Verzeichniskomponenten enthalten. Diese Verzeichnisse werden sein
im Suchpfad enthalten. Zum Beispiel:

django-admin lädt Daten foo/bar/mydata.json

würde suchen /fixtures/foo/bar/mydata.json für jede installierte Anwendung,
/foo/bar/mydata.json für jedes Verzeichnis in FIXTURE_DIRSund der wörtliche Pfad
foo/bar/mydata.json.

Wenn Fixture-Dateien verarbeitet werden, werden die Daten unverändert in der Datenbank gespeichert. Modell definiert
speichern() Methoden werden nicht aufgerufen, und alle pre_save or post_speichern Signale werden mit aufgerufen
raw=Wahr da die Instanz nur Attribute enthält, die lokal für das Modell sind. Sie können,
Sie möchten beispielsweise Handler deaktivieren, die auf verwandte Felder zugreifen, die nicht vorhanden sind
beim Laden des Fixtures und würde andernfalls eine Ausnahme auslösen:

aus django.db.models.signals import post_save
aus .models MyModel importieren

def my_handler(**kwargs):
# Deaktivieren Sie den Handler während des Ladens des Fixtures
wenn kwargs['raw']:
Rückkehr
...

post_save.connect(my_handler, sender=MyModel)

Sie könnten auch einen einfachen Dekorator schreiben, um diese Logik zu kapseln:

von functools importieren Wraps

defdisable_for_loaddata(signal_handler):
"" "
Decorator, der Signalhandler beim Laden von Fixture-Daten deaktiviert.
"" "
@wraps(signal_handler)
def-Wrapper(*args, **kwargs):
wenn kwargs['raw']:
Rückkehr
signal_handler(*args, **kwargs)
Rückverpackung

@disable_for_loaddata
def my_handler(**kwargs):
...

Beachten Sie jedoch, dass diese Logik die Signale deaktiviert, wenn Geräte deserialisiert werden.
nicht nur während lade Daten.

Beachten Sie, dass die Reihenfolge, in der Fixture-Dateien verarbeitet werden, nicht definiert ist. Allerdings alle
Gerätedaten werden als einzelne Transaktion installiert, sodass Daten in einem Gerät referenziert werden können
Daten in einem anderen Gerät. Wenn das Datenbank-Backend Einschränkungen auf Zeilenebene unterstützt, sind diese
Einschränkungen werden am Ende der Transaktion überprüft.

Die Dumpdaten Der Befehl kann verwendet werden, um Eingaben für zu generieren lade Daten.

Komprimierte Armaturen
Vorrichtungen können eingestaucht werden Reißverschluss, gz oder bz2 Format. Zum Beispiel:

django-admin lädt Daten mydata.json

würde nach irgendetwas davon suchen mydata.json, mydata.json.zip, mydata.json.gz oder mydata.json.bz2.
Es wird die erste Datei verwendet, die in einem ZIP-komprimierten Archiv enthalten ist.

Beachten Sie, dass zwei Geräte mit demselben Namen, aber unterschiedlichem Gerätetyp erkannt werden
(zum Beispiel, wenn mydata.json und mydata.xml.gz wurden im selben Fixture-Verzeichnis gefunden),
Die Installation des Geräts wird abgebrochen und alle im Aufruf installierten Daten werden gelöscht lade Daten werden wir
aus der Datenbank entfernt werden.

MySQL mit MyISAM und Fixtures

Die MyISAM-Speicher-Engine von MySQL unterstützt keine Transaktionen oder Einschränkungen.
Wenn Sie also MyISAM verwenden, erhalten Sie keine Validierung der Fixture-Daten und ggf. auch kein Rollback
Es wurden mehrere Transaktionsdateien gefunden.

Datenbankspezifisch Armaturen
Wenn Sie in einem Multi-Datenbank-Setup arbeiten, verfügen Sie möglicherweise über Vorrichtungsdaten, die Sie laden möchten
auf eine Datenbank, aber nicht auf eine andere. In dieser Situation können Sie eine Datenbank hinzufügen
Identifikator in die Namen Ihrer Geräte ein.

Zum Beispiel, wenn Ihr DATENBANKEN Wenn in der Einstellung eine „Master“-Datenbank definiert ist, benennen Sie das Gerät
mydata.master.json or mydata.master.json.gz und das Gerät wird nur geladen, wenn Sie
Geben Sie an, dass Sie Daten in das laden möchten führen zu Datenbank.

Nachrichten machen
django-admin Nachrichten machen

Läuft über den gesamten Quellbaum des aktuellen Verzeichnisses und ruft alle markierten Zeichenfolgen ab
zur Übersetzung. Es erstellt (oder aktualisiert) eine Nachrichtendatei im conf/locale (im Django
Baum) oder Gebietsschema (für Projekt und Anwendung) Verzeichnis. Nachdem Sie Änderungen an der vorgenommen haben
Nachrichtendateien, mit denen Sie sie kompilieren müssen Nachrichten kompilieren zur Verwendung mit dem eingebauten
gettext-Unterstützung. Siehe die i18n Dokumentation .

--alle

Verwenden Sie das --alle or -a Option zum Aktualisieren der Nachrichtendateien für alle verfügbaren Sprachen.

Beispielverwendung:

django-admin makemessages --all

--Verlängerung

Verwenden Sie das --Verlängerung or -e Option zum Angeben einer Liste der zu untersuchenden Dateierweiterungen (Standard:
„.html“, „.txt“).

Beispielverwendung:

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

Trennen Sie mehrere Erweiterungen durch Kommas oder verwenden Sie -e oder --extension mehrmals:

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

Verwenden Sie das - Gebietsschema Option (oder ihre kürzere Version). -l), um die zu verarbeitenden Gebietsschema(s) anzugeben.

Verwenden Sie das --ausschließen Option (oder ihre kürzere Version). -x), um die auszuschließenden Gebietsschema(s) anzugeben
aus der Verarbeitung. Wenn nicht angegeben, werden keine Gebietsschemas ausgeschlossen.

Beispielverwendung:

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

Hinzugefügt --früher Option zum msgmerge Befehl beim Zusammenführen mit vorhandenen PO-Dateien.

--Domain

Verwenden Sie das --Domain or -d Option zum Ändern der Domäne der Nachrichtendateien. Momentan
unterstützt:

· django für alle *.py, *.html und * .txt Dateien (Standard)

· djangojs für *.js Dateien

- Symlinks

Verwenden Sie das - Symlinks or -s Option, bei der Suche nach neuen Symlinks zu Verzeichnissen zu folgen
Übersetzungszeichenfolgen.

Beispielverwendung:

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

--ignorieren

Verwenden Sie das --ignorieren or -i Option zum Ignorieren von Dateien oder Verzeichnissen, die dem angegebenen entsprechen KlacksStil
Muster. Mehrmals verwenden, um mehr zu ignorieren.

Diese Muster werden standardmäßig verwendet: 'CVS', '.*', '*~', '*.pyc'

Beispielverwendung:

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

--no-default-ignore

Verwenden Sie das --no-default-ignore Option zum Deaktivieren der Standardwerte von --ignorieren.

--no-wrap

Verwenden Sie das --no-wrap Option zum Deaktivieren der Aufteilung langer Nachrichtenzeilen in mehrere Zeilen in
Sprachdateien.

--no-__cpLocation

Verwenden Sie das --no-__cpLocation Option, nicht zu schreiben '#: Dateiname:Zeile' Kommentarzeilen in der Sprache
Dateien. Beachten Sie, dass die Verwendung dieser Option für technisch versierte Übersetzer schwieriger ist
den Kontext jeder Nachricht verstehen.

--keep-pot

Verwenden Sie das --keep-pot Option, um zu verhindern, dass Django die temporären Debugfehler löscht
Dies kann dazu führen, dass die endgültigen Sprachdateien nicht erstellt werden.

SEHEN EBENFALLS:
Weitere Informationen finden Sie auch in den Customizing-Makemessages Anweisungen zum Anpassen der Schlüsselwörter finden Sie hier
Nachrichten machen geht an xgettext.

Makemigrationen [ ]
django-admin Makemigrationen

Erstellt neue Migrationen basierend auf den an Ihren Modellen erkannten Änderungen. Migrationen, ihre
Beziehung zu Apps und mehr werden ausführlich behandelt die Migration Dokumentation.

Durch die Angabe eines oder mehrerer App-Namen als Argumente werden die erstellten Migrationen auf die beschränkt
angegebene App(s) und alle erforderlichen Abhängigkeiten (die Tabelle am anderen Ende von a Unbekannter Schlüssel,
zum Beispiel).

--leer

Die --leer Option wird verursachen Makemigrationen um eine leere Migration für die auszugeben
bestimmte Apps zur manuellen Bearbeitung. Diese Option ist nur für fortgeschrittene Benutzer gedacht und sollte nicht verwendet werden
verwendet werden, es sei denn, Sie sind mit dem Migrationsformat, den Migrationsvorgängen usw. vertraut
Abhängigkeiten zwischen Ihren Migrationen.

--Probelauf

Die --Probelauf Die Option zeigt an, welche Migrationen durchgeführt würden, ohne tatsächlich welche zu schreiben
Migration von Dateien auf die Festplatte. Verwenden Sie diese Option zusammen mit --ausführlich 3 wird auch das zeigen
vollständige Migrationsdateien, die geschrieben werden würden.

--verschmelzen

Die --verschmelzen Option ermöglicht die Behebung von Migrationskonflikten. Der --keine Eingabe Option kann sein
Wird bereitgestellt, um Benutzeraufforderungen während einer Zusammenführung zu unterdrücken.

--Name, -n

Die --Name Mit dieser Option können Sie der/den Migration(en) einen benutzerdefinierten Namen anstelle eines generierten Namens geben
eins.

--Ausfahrt, -e

Die --Ausfahrt Option wird verursachen Makemigrationen mit Fehlercode 1 beenden, wenn keine Migration erfolgt
erstellt werden (oder erstellt worden wären, wenn sie mit kombiniert würden). --Probelauf).

migriert [ [ ]]
django-admin migriert

Synchronisiert den Datenbankstatus mit dem aktuellen Satz von Modellen und Migrationen.
Migrationen, ihre Beziehung zu Apps und mehr werden ausführlich behandelt die Migration
Dokumentation.

Das Verhalten dieses Befehls ändert sich abhängig von den angegebenen Argumenten:

· Keine Argumente: Bei allen migrierten Apps werden alle Migrationen ausgeführt und alle werden nicht migriert
Apps werden mit der Datenbank synchronisiert,

· : Die Migrationen der angegebenen App werden bis zur letzten Migration ausgeführt.
Aufgrund von Abhängigkeiten kann dies auch die Durchführung von Migrationen anderer Apps erfordern.

· : Bringt das Datenbankschema in einen Zustand, in dem der Name angegeben ist
Die Migration wird angewendet, spätere Migrationen in derselben App werden jedoch nicht angewendet. Das vielleicht
Dies beinhaltet das Aufheben der Anwendung von Migrationen, wenn Sie zuvor über die genannte Migration hinaus migriert haben.
Benutze den Namen Null um alle Migrationen für eine App rückgängig zu machen.

Im Gegensatz zu syncdb, fordert Sie dieser Befehl nicht dazu auf, einen Superuser zu erstellen, wenn noch keiner vorhanden ist
(vorausgesetzt, Sie verwenden django.contrib.auth). Benutzen erstelltsuperuser das zu tun, wenn Sie möchten.

Die --Datenbank Mit der Option kann die zu migrierende Datenbank angegeben werden.

--gefälscht

Die --gefälscht Die Option weist Django an, die Migrationen als angewendet oder nicht angewendet zu markieren.
aber ohne tatsächlich die SQL auszuführen, um Ihr Datenbankschema zu ändern.

Dies ist für fortgeschrittene Benutzer gedacht, um den aktuellen Migrationsstatus direkt zu manipulieren
Sie wenden Änderungen manuell an. Seien Sie gewarnt, dass mit --gefälscht läuft Gefahr zu stecken
die Migrationsstatustabelle in einen Zustand, in dem eine manuelle Wiederherstellung erforderlich ist
Migrationen werden korrekt ausgeführt.

--fake-initial

Die --fake-initial Mit der Option kann Django erlaubt werden, die anfängliche Migration einer App zu überspringen
wenn alle Datenbanktabellen mit den Namen aller von allen erstellten Modelle Modell erstellen Geschäftstätigkeit
in dieser Migration gibt es bereits. Diese Option ist für die Verwendung beim ersten Start gedacht
Migrationen gegen eine Datenbank, die bereits vor der Verwendung von Migrationen vorhanden war. Diese Option funktioniert nicht,
Es wird jedoch nur nach übereinstimmenden Datenbankschemata gesucht, die über übereinstimmende Tabellennamen hinausgehen
Die Verwendung ist sicher, wenn Sie sicher sind, dass Ihr vorhandenes Schema mit den Aufzeichnungen übereinstimmt
Ihre erste Migration.

Veraltet seit Version 1.8: Die --aufführen Die Option wurde in die verschoben Showmigrationen
Befehl.

runfcgi [Optionen]
django-admin runfcgi

Veraltet seit Version 1.7: Die FastCGI-Unterstützung ist veraltet und wird in Django entfernt
1.9

Startet eine Reihe von FastCGI-Prozessen, die für die Verwendung mit jedem Webserver geeignet sind, der das unterstützt
FastCGI-Protokoll. Siehe die SchnellCGI Einsatz Dokumentation für Details. Erfordert die
Python FastCGI-Modul von fluchen.

Intern wird dadurch das von angegebene WSGI-Anwendungsobjekt umschlossen WSGI_APPLICATION
Einstellung.

Die von diesem Befehl akzeptierten Optionen werden an die FastCGI-Bibliothek übergeben und verwenden die nicht
'--' Präfix, wie es für andere Django-Verwaltungsbefehle üblich ist.

Protokoll

Protokoll=PROTOKOLL

Zu verwendendes Protokoll. PROTOKOLL kann sein fcgi, scgi, ajpusw. (Standard ist fcgi)

Gastgeber

host=HOSTNAME

Hostname zum Abhören.

port

port=PORTNUM

Port zum Abhören.

Buchse

socket=DATEI

UNIX-Socket zum Abhören.

Methode

method=IMPL

Mögliche Werte: prefork or eingefädelt (Standard prefork)

maxrequests

maxrequests=ANZAHL

Anzahl der Anfragen, die ein Kind bearbeitet, bevor es getötet und ein neues Kind geforkt wird (0 bedeutet).
keine Begrenzung).

maxspare

maxspare=ANZAHL

Maximale Anzahl freier Prozesse/Threads.

minspar

minspare=ANZAHL

Mindestanzahl an Ersatzprozessen/Threads.

maxchildren

maxchildren=ANZAHL

Fest begrenzte Anzahl von Prozessen/Threads.

dämonisieren

daemonize=BOOL

Ob vom Terminal getrennt werden soll.

pid-Datei

pidfile=DATEI

Schreiben Sie die erzeugte Prozess-ID in die Datei FILE.

Arbeitsverzeichnis

workdir=VERZEICHNIS

Wechseln Sie in das Verzeichnis DIRECTORY beim Dämonisieren.

debuggen

debug=BOOL

Auf „true“ setzen, um Flup-Tracebacks zu aktivieren.

outlog

outlog=DATEI

Schreiben Sie stdout in die FILE Datei.

Fehlerprotokoll

errlog=DATEI

Schreiben Sie stderr in die FILE Datei.

umask

umask=UMASK

Umask, das beim Daemonisieren verwendet werden soll. Der Wert wird als Oktalzahl interpretiert (Standardwert).
is 0o22).

Beispielverwendung:

django-admin runfcgi socket=/tmp/fcgi.sock method=prefork daemonize=true
pidfile=/var/run/django-fcgi.pid

Führen Sie einen FastCGI-Server als Daemon aus und schreiben Sie die erzeugte PID in eine Datei.

runserver [Hafen or Adresse:Port]
django-admin runserver

Startet einen einfachen Entwicklungs-Webserver auf dem lokalen Computer. Standardmäßig der Server
läuft auf Port 8000 der IP-Adresse 127.0.0.1. Sie können eine IP-Adresse und einen Port eingeben
Nummer explizit angeben.

Wenn Sie dieses Skript als Benutzer mit normalen Berechtigungen ausführen (empfohlen), ist dies möglicherweise nicht der Fall
Zugriff, um einen Port auf einer niedrigen Portnummer zu starten. Für die sind niedrige Portnummern reserviert
Superuser (root).

Dieser Server verwendet das von angegebene WSGI-Anwendungsobjekt WSGI_APPLICATION Einstellung.

VERWENDEN SIE DIESEN SERVER NICHT IN EINER PRODUKTIONSEINSTELLUNG. Es wurden keine Sicherheitsüberprüfungen durchgeführt oder
Leistungstests. (Und so wird es auch bleiben. Wir sind im Geschäft, Web zu machen
Frameworks, keine Webserver. Daher muss dieser Server verbessert werden, um eine Produktion abwickeln zu können
Umgebung liegt außerhalb des Geltungsbereichs von Django.)

Der Entwicklungsserver lädt bei Bedarf automatisch den Python-Code für jede Anfrage neu. Du
Sie müssen den Server nicht neu starten, damit die Codeänderungen wirksam werden. Allerdings einige Aktionen
Das Hinzufügen von Dateien löst beispielsweise keinen Neustart aus, sodass Sie in diesen Fällen den Server neu starten müssen
Fälle.

Beim Kompilieren der Übersetzungsdateien wird nun auch der Entwicklungsserver neu gestartet.

Wenn Sie Linux verwenden und installieren pynotifizieren, Kernel-Signale werden zum automatischen Neuladen verwendet
den Server (anstatt jede Sekunde die Zeitstempel der Dateiänderungen abzufragen). Das bietet
bessere Skalierung auf große Projekte, Verkürzung der Reaktionszeit auf Codeänderungen usw
Robuste Änderungserkennung und Reduzierung des Batterieverbrauchs.

pynotifizieren Unterstützung wurde hinzugefügt.

Wenn Sie den Server starten und jedes Mal, wenn Sie den Python-Code ändern, während der Server läuft
Wenn es ausgeführt wird, überprüft der Server Ihr gesamtes Django-Projekt auf Fehler (siehe aus der Ferne überprüfen
Befehl). Wenn Fehler gefunden werden, werden diese auf der Standardausgabe ausgegeben, was jedoch nicht der Fall ist
Stoppen Sie den Server.

Sie können so viele Server betreiben, wie Sie möchten, solange sie sich auf separaten Ports befinden. Nur
ausführen django-admin runserver mehr als einmal.

Beachten Sie, dass die Standard-IP-Adresse 127.0.0.1, ist nicht von anderen Computern auf Ihrem Computer aus zugänglich
Netzwerk. Um Ihren Entwicklungsserver für andere Computer im Netzwerk sichtbar zu machen, verwenden Sie
seine eigene IP-Adresse (z 192.168.2.1oder 0.0.0.0 or :: (mit aktiviertem IPv6).

Sie können eine IPv6-Adresse in Klammern angeben (z. B [200a::1]:8000). Dieser Wille
IPv6-Unterstützung automatisch aktivieren.

Es kann auch ein Hostname verwendet werden, der nur ASCII-Zeichen enthält.

Besitzt das statische Dateien Die Contrib-App ist aktiviert (Standard in neuen Projekten). runserver Befehl
wird mit seinem eigenen überschrieben runserver Befehl.

If migriert nicht zuvor ausgeführt wurde, ist dies die Tabelle, in der der Verlauf der Migrationen gespeichert ist
erstellt beim ersten Durchlauf von runserver.

--kein Neuladen

Verwenden Sie das --kein Neuladen Option zum Deaktivieren der Verwendung des automatischen Nachladers. Damit ist jedes Python gemeint
Codeänderungen, die Sie vornehmen, während der Server läuft, werden dies tun nicht wirksam werden, wenn die jeweilige
Python-Module wurden bereits in den Speicher geladen.

Beispielverwendung:

django-admin runserver --noreload

--notreading

Der Entwicklungsserver ist standardmäßig multithreaded. Benutzen Sie die --notreading Option zu
Deaktivieren Sie die Verwendung von Threading im Entwicklungsserver.

--ipv6, -6

Verwenden Sie das --ipv6 (oder kürzer -6) Option, um Django anzuweisen, IPv6 für die Entwicklung zu verwenden
Server. Dadurch ändert sich die Standard-IP-Adresse von 127.0.0.1 zu :: 1.

Beispielverwendung:

django-admin runserver --ipv6

Beispiele of mit automatisierten anders sein kann oder ander sein wird Häfen und Adressen
Port 8000 auf IP-Adresse 127.0.0.1:

Django-Admin-Runserver

Port 8000 auf IP-Adresse 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Port 7000 auf IP-Adresse 127.0.0.1:

django-admin runserver 7000

Port 7000 auf IP-Adresse 1.2.3.4:

django-admin runserver 1.2.3.4:7000

Port 8000 auf IPv6-Adresse :: 1:

django-admin runserver -6

Port 7000 auf IPv6-Adresse :: 1:

django-admin runserver -6 7000

Port 7000 auf IPv6-Adresse 2001:0db8:1234:5678::9:

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

Port 8000 auf der IPv4-Adresse des Hosts localhost:

django-admin runserver localhost:8000

Port 8000 auf der IPv6-Adresse des Hosts localhost:

django-admin runserver -6 localhost:8000

Geschirr statisch Dateien mit die Entwicklung Server
Standardmäßig stellt der Entwicklungsserver keine statischen Dateien für Ihre Site bereit (z. B
CSS-Dateien, Bilder, Dinge darunter MEDIA_URL und so weiter). Wenn Sie Django konfigurieren möchten
Um statische Medien bereitzustellen, lesen Sie /howto/static-files/index.

Schale
django-admin Schale

Startet den interaktiven Python-Interpreter.

Django wird verwenden IPython or python wenn eines davon installiert ist. Wenn Sie eine reichhaltige Muschel haben
installiert, möchten aber die Verwendung des „einfachen“ Python-Interpreters erzwingen, verwenden Sie den --schlicht Option,
so:

Django-Admin-Shell --plain

Wenn Sie entweder IPython oder Bpython als Interpreter angeben möchten, falls vorhanden
Wenn beide installiert sind, können Sie mit dem eine alternative Interpreterschnittstelle angeben -i or
--Schnittstelle Optionen wie diese:

IPython:

Django-Admin-Shell -i ipython
Django-Admin-Shell --interface ipython

bpython:

django-admin-Shell -i bpython
django-admin-Shell --interface bpython

Wenn der „einfache“ interaktive Python-Interpreter startet (sei es, weil --schlicht wurde
angegeben ist oder weil keine andere interaktive Schnittstelle verfügbar ist), liest es das Skript
darauf hingewiesen durch die PYTHONSTARTUP Umgebungsvariable und die ~/.pythonrc.py Skript. Wenn du
Wenn Sie dieses Verhalten nicht wünschen, können Sie es verwenden --no-startup Möglichkeit. z.B:

Django-Admin-Shell --plain --no-startup

Showmigrationen [ [ ]]
django-admin Showmigrationen

Zeigt alle Migrationen in einem Projekt an.

--Liste, -l

Die --aufführen Die Option listet alle Apps auf, die Django kennt, und die verfügbaren Migrationen
jede App und ob jede Migration angewendet wird oder nicht (gekennzeichnet durch ein [X] neben dem
Migrationsname).

Apps ohne Migrationen werden ebenfalls aufgeführt, haben dies jedoch getan Nein Migrationen) darunter gedruckt.

--planen, -p

Die --planen Die Option zeigt den Migrationsplan an, dem Django folgen wird, um Migrationen anzuwenden. Beliebig
Die bereitgestellten App-Labels werden ignoriert, da der Plan möglicherweise über diese Apps hinausgeht. Gleich wie
--aufführen, angewendete Migrationen sind mit einem gekennzeichnet [X]. Für eine Ausführlichkeit von 2 und höher: alle
Abhängigkeiten einer Migration werden ebenfalls angezeigt.

SQL <app_label app_label ...>
django-admin SQL

Gibt die CREATE TABLE-SQL-Anweisungen für die angegebenen App-Namen aus.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL gedruckt werden soll.

sqlall <app_label app_label ...>
django-admin sqlall

Druckt die CREATE TABLE- und Anfangsdaten-SQL-Anweisungen für die angegebenen App-Namen.

Siehe Beschreibung von sqlbenutzerdefiniert eine Erläuterung zur Angabe der Anfangsdaten.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL gedruckt werden soll.

Die SQL* Managementbefehle respektieren jetzt die allow_migrate() Methode von DATABASE_ROUTERS.
Wenn Sie Modelle mit nicht standardmäßigen Datenbanken synchronisiert haben, verwenden Sie die --Datenbank Flag, für das SQL abgerufen werden soll
diese Modelle (zuvor waren sie immer in der Ausgabe enthalten).

sqlclear <app_label app_label ...>
django-admin sqlclear

Gibt die DROP TABLE-SQL-Anweisungen für die angegebenen App-Namen aus.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL gedruckt werden soll.

sqlbenutzerdefiniert <app_label app_label ...>
django-admin sqlbenutzerdefiniert

Gibt die benutzerdefinierten SQL-Anweisungen für die angegebenen App-Namen aus.

Für jedes Modell in jeder angegebenen App sucht dieser Befehl nach der Datei
/sql/ .sql, Wobei ist der angegebene App-Name und
ist der Name des Modells in Kleinbuchstaben. Zum Beispiel, wenn Sie eine App haben News das schließt ein
Geschichte Modell, sqlbenutzerdefiniert wird versuchen, eine Datei zu lesen news/sql/story.sql und hängen Sie es an die an
Ausgabe dieses Befehls.

Es wird erwartet, dass jede der SQL-Dateien, sofern angegeben, gültiges SQL enthält. Die SQL-Dateien werden weitergeleitet
direkt in die Datenbank, nachdem alle Tabellenerstellungsanweisungen der Modelle ausgeführt wurden
hingerichtet. Verwenden Sie diesen SQL-Hook, um Tabellenänderungen vorzunehmen oder SQL-Funktionen einzufügen
in die Datenbank.

Beachten Sie, dass die Reihenfolge, in der die SQL-Dateien verarbeitet werden, nicht definiert ist.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL gedruckt werden soll.

sqldropindexes <app_label app_label ...>
django-admin sqldropindexes

Druckt die DROP INDEX SQL-Anweisungen für die angegebenen App-Namen.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL gedruckt werden soll.

sqlflush
django-admin sqlflush

Druckt die SQL-Anweisungen, die für ausgeführt werden würden spülen Befehl.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL gedruckt werden soll.

SQL-Indizes <app_label app_label ...>
django-admin SQL-Indizes

Druckt die CREATE INDEX SQL-Anweisungen für die angegebenen App-Namen.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL gedruckt werden soll.

sqlmigrate
django-admin sqlmigrate

Druckt die SQL für die benannte Migration. Dies erfordert eine aktive Datenbankverbindung, die
es wird zum Auflösen von Einschränkungsnamen verwendet; das bedeutet, dass Sie die SQL gegen a generieren müssen
Kopie der Datenbank, auf die Sie sie später anwenden möchten.

Beachten Sie, dass sqlmigrate färbt seine Ausgabe nicht ein.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL generiert werden soll.

--rückwärts

Standardmäßig dient die erstellte SQL dazu, die Migration in Vorwärtsrichtung auszuführen. Passieren
--rückwärts um stattdessen die SQL zum Aufheben der Anwendung der Migration zu generieren.

sqlsequenzereset <app_label app_label ...>
django-admin sqlsequenzereset

Druckt die SQL-Anweisungen zum Zurücksetzen von Sequenzen für die angegebenen App-Namen.

Sequenzen sind Indizes, die von einigen Datenbank-Engines verwendet werden, um die nächste verfügbare Nummer zu verfolgen
automatisch inkrementierte Felder.

Verwenden Sie diesen Befehl, um SQL zu generieren, das Fälle behebt, in denen eine Sequenz nicht synchron ist
seine automatisch inkrementierten Felddaten.

Die --Datenbank Mit der Option kann die Datenbank angegeben werden, für die die SQL gedruckt werden soll.

Squashmigrationen
django-admin Squashmigrationen

Unterdrückt die Migrationen für app_label bis einschließlich Migrationsname in weniger reduziert
Migrationen, wenn möglich. Die daraus resultierenden gequetschten Migrationen können nebenher leben
ungequetschte sicher. Für weitere Informationen lesen Sie bitte Migrationsunterdrückung.

--no-optimize

Standardmäßig versucht Django, die Vorgänge in Ihren Migrationen zu optimieren, um die zu reduzieren
Größe der resultierenden Datei. Passieren --no-optimize wenn dieser Prozess für Sie fehlschlägt oder
Erstellen fehlerhafter Migrationen, reichen Sie jedoch bitte auch einen Django-Fehlerbericht darüber ein
Verhalten, denn Optimierung soll sicher sein.

Startapp [Ziel]
django-admin Startapp

Erstellt eine Django-App-Verzeichnisstruktur für den angegebenen App-Namen im aktuellen Verzeichnis
oder das angegebene Ziel.

Standardmäßig enthält das erstellte Verzeichnis a modelle.py Datei und andere App-Vorlagendateien.
(Siehe die Quelle für weitere Details.) Wenn nur der App-Name angegeben wird, wird das App-Verzeichnis angegeben
im aktuellen Arbeitsverzeichnis erstellt werden.

Wenn das optionale Ziel angegeben wird, verwendet Django stattdessen dieses vorhandene Verzeichnis
als ein neues zu erstellen. Sie können „.“ verwenden. um das aktuelle Arbeitsverzeichnis anzugeben.

Beispielsweise:

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

--Vorlage

Mit der --Vorlage Option können Sie eine benutzerdefinierte App-Vorlage verwenden, indem Sie entweder den Pfad angeben
in ein Verzeichnis mit der App-Vorlagendatei oder einen Pfad zu einer komprimierten Datei (.tar.gz,
.tar.bz2, . Tgz, .tbz, .zip), die die App-Vorlagendateien enthält.

Dies würde beispielsweise beim Erstellen der App im angegebenen Verzeichnis nach einer App-Vorlage suchen
meine App App:

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

Django akzeptiert auch URLs (http, https, ftp) in komprimierte Archive mit der App
Erstellen Sie Vorlagendateien, laden Sie sie im Handumdrehen herunter und extrahieren Sie sie.

Wenn Sie beispielsweise die Funktion von Github nutzen, um Repositorys als ZIP-Dateien bereitzustellen, können Sie
kann eine URL wie diese verwenden:

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

Wenn Django die App-Vorlagendateien kopiert, rendert es auch bestimmte Dateien über
Template-Engine: die Dateien, deren Erweiterungen mit der übereinstimmen --Verlängerung Option (py standardmäßig)
und die Dateien, deren Namen mit übergeben werden --Name Option. Die Vorlage Kontext verwendet wird:

· Jede an die übergebene Option Startapp Befehl (unter den unterstützten Optionen des Befehls)

· App Name – der App-Name, wie er an den Befehl übergeben wurde

· app_directory – der vollständige Pfad der neu erstellten App

· docs_version -- die Version der Dokumentation: 'Entwickler' or '1.x'

WARNUNG: Wichtige Mitteilung
Wenn die App-Vorlagendateien mit der Django-Vorlagen-Engine gerendert werden (standardmäßig).
alle *.py Dateien) ersetzt Django auch alle enthaltenen verirrten Vorlagenvariablen. Für
Beispiel: Eine der Python-Dateien enthält eine Dokumentzeichenfolge, die eine bestimmte Sache erklärt
Wenn Sie eine Funktion im Zusammenhang mit dem Rendern von Vorlagen verwenden, kann dies zu einem falschen Beispiel führen.

Um dieses Problem zu umgehen, können Sie Folgendes verwenden Vorlagentag templatetag, um dem zu „entkommen“.
verschiedene Teile der Vorlagensyntax.

startprojekt [Ziel]
django-admin startprojekt

Erstellt eine Django-Projektverzeichnisstruktur für den angegebenen Projektnamen im aktuellen
Verzeichnis oder das angegebene Ziel.

Standardmäßig enthält das neue Verzeichnis manage.py und ein Projektpaket (enthält a
settings.py und andere Dateien). Siehe die Vorlage Quelle .

Wenn nur der Projektname angegeben wird, werden sowohl das Projektverzeichnis als auch das Projektpaket angegeben
namens und das Projektverzeichnis wird im aktuellen Arbeitsverzeichnis erstellt
Verzeichnis.

Wenn das optionale Ziel angegeben wird, verwendet Django dieses vorhandene Verzeichnis als
Projektverzeichnis und erstellen manage.py und das darin enthaltene Projektpaket. Verwenden '.' Zu
bezeichnen das aktuelle Arbeitsverzeichnis.

Beispielsweise:

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

Wie bei der Startapp Befehl, der --Vorlage Mit der Option können Sie ein Verzeichnis oder eine Datei angeben
Pfad oder URL einer benutzerdefinierten Projektvorlage. Siehe die Startapp Einzelheiten dazu finden Sie in der Dokumentation
Unterstützte Projektvorlagenformate.

Dies würde beispielsweise beim Erstellen nach einer Projektvorlage im angegebenen Verzeichnis suchen
die Mein Projekt Projekt:

django-admin startproject --template=/Users/jezdez/Code/my_project_template meinprojekt

Django akzeptiert auch URLs (http, https, ftp) in komprimierte Archive mit dem Projekt
Erstellen Sie Vorlagendateien, laden Sie sie im Handumdrehen herunter und extrahieren Sie sie.

Wenn Sie beispielsweise die Funktion von Github nutzen, um Repositorys als ZIP-Dateien bereitzustellen, können Sie
kann eine URL wie diese verwenden:

django-admin startproject --template=https://github.com/githubuser/django-project-template/archive/master.zip meinprojekt

Wenn Django die Projektvorlagendateien kopiert, rendert es auch bestimmte Dateien über
Template-Engine: die Dateien, deren Erweiterungen mit der übereinstimmen --Verlängerung Option (py standardmäßig)
und die Dateien, deren Namen mit übergeben werden --Name Option. Die Vorlage Kontext verwendet wird:

· Jede an die übergebene Option startprojekt Befehl (unter den unterstützten Optionen des Befehls)

· Projektname – der Projektname, wie er an den Befehl übergeben wurde

· Projektverzeichnis – der vollständige Pfad des neu erstellten Projekts

· geheimer Schlüssel – ein zufälliger Schlüssel für die GEHEIMER SCHLÜSSEL Einstellung

· docs_version -- die Version der Dokumentation: 'Entwickler' or '1.x'

Bitte beachten Sie auch die Rendering Warnung wie erwähnt für Startapp.

syncdb
django-admin syncdb

Veraltet seit Version 1.7: Dieser Befehl wurde zugunsten von veraltet migriert
Befehl, der sowohl das alte Verhalten ausführt als auch Migrationen ausführt. Ist das jetzt
nur ein Alias ​​für diesen Befehl.

Alias ​​für migriert.

Test <App or Test Bezeichner>
django-admin Test

Führt Tests für alle installierten Modelle durch. Sehen /topics/testing/index .

--Failfast

Die --Failfast Mit dieser Option können Sie die Ausführung von Tests stoppen und den Fehler sofort melden
nachdem ein Test fehlgeschlagen ist.

--testrunner

Die --testrunner Mit dieser Option kann die gewohnte Test-Runner-Klasse gesteuert werden
Tests durchführen. Wenn dieser Wert angegeben wird, überschreibt er den von bereitgestellten Wert
TEST_RUNNER Einstellung.

--liveserver

Die --liveserver Die Option kann verwendet werden, um die Standardadresse des Live-Servers zu überschreiben
(benutzt mit LiveServerTestCase) wird voraussichtlich ausgeführt. Der Standardwert ist
localhost: 8081.

--keepdb

Die --keepdb Die Option kann verwendet werden, um die Testdatenbank zwischen Testläufen beizubehalten. Das hat
Der Vorteil besteht darin, sowohl die Erstellungs- als auch die Zerstörungsaktion zu überspringen, was die Kosten erheblich verringert
Zeit zum Ausführen von Tests, insbesondere in einer großen Testsuite. Wenn die Testdatenbank dies nicht tut
vorhanden ist, wird es beim ersten Durchlauf erstellt und dann für jeden weiteren Durchlauf beibehalten. Beliebig
Nicht angewendete Migrationen werden ebenfalls auf die Testdatenbank angewendet, bevor der Test ausgeführt wird
Suite.

--umkehren

Die --umkehren Mit dieser Option können Testfälle in umgekehrter Reihenfolge sortiert werden. Das kann helfen
bei Debugging-Tests, die nicht ordnungsgemäß isoliert sind und Nebenwirkungen haben. Gruppierung by Test
Klasse bleibt bei Verwendung dieser Option erhalten.

--debug-sql

Die --debug-sql Option kann zum Aktivieren verwendet werden SQL Protokollierung für nicht bestandene Tests. Wenn --ausführlich
is 2, dann werden auch Abfragen in bestandenen Tests ausgegeben.

Testserver <Gerät Befestigung ...>
django-admin Testserver

Führt einen Django-Entwicklungsserver aus (wie in runserver) unter Verwendung der Daten der angegebenen Vorrichtung(en).

Zum Beispiel dieser Befehl:

django-admin testserver mydata.json

...würde die folgenden Schritte ausführen:

1. Erstellen Sie eine Testdatenbank, wie in beschrieben die-test-datenbank.

2. Füllen Sie die Testdatenbank mit Vorrichtungsdaten der angegebenen Vorrichtungen. (Weitere Informationen zu
Weitere Informationen zu den Vorrichtungen finden Sie in der Dokumentation lade Daten über.)

3. Führt den Django-Entwicklungsserver aus (wie in runserver), wies auf dieses neu geschaffene hin
Testdatenbank anstelle Ihrer Produktionsdatenbank.

Dies ist in mehrfacher Hinsicht nützlich:

· Wenn Sie schreiben Einheit Tests Wie sich Ihre Ansichten mit bestimmten Fixture-Daten verhalten, können Sie ermitteln
- Testserver um manuell mit den Ansichten in einem Webbrowser zu interagieren.

· Nehmen wir an, Sie entwickeln Ihre Django-Anwendung und verfügen über eine „unberührte“ Kopie einer
Datenbank, mit der Sie interagieren möchten. Sie können Ihre Datenbank auf einem Gerät sichern
(Verwendung der Dumpdaten Befehl, oben erklärt), dann verwenden Testserver um Ihr Web zu betreiben
Anwendung mit diesen Daten. Mit dieser Anordnung haben Sie die Flexibilität, herumzuspielen
Aktualisieren Sie Ihre Daten in irgendeiner Weise, in dem Wissen, dass alle von Ihnen vorgenommenen Datenänderungen nur vorgenommen werden
in eine Testdatenbank übernommen.

Beachten Sie, dass dieser Server dies tut nicht Erkennt automatisch Änderungen an Ihrem Python-Quellcode (wie
runserver tut). Es erkennt jedoch Änderungen an Vorlagen.

--addrport [Hafen Anzahl or ipaddr:port]

Nutzen Sie --addrport um einen anderen Port oder eine andere IP-Adresse und einen anderen Port als die Standardeinstellung anzugeben
127.0.0.1:8000. Dieser Wert hat genau das gleiche Format und dient genau dem gleichen Zweck
Funktion als Argument für die runserver Befehl.

Beispiele:

Um den Testserver auf Port 7000 laufen zu lassen Vorrichtung1 und Vorrichtung2:

django-admin testserver --addrport 7000 Fixture1 Fixture2
django-admin testserver Fixture1 Fixture2 --addrport 7000

(Die obigen Aussagen sind gleichwertig. Wir schließen beide ein, um zu zeigen, dass dies der Fall ist
Dabei spielt es keine Rolle, ob die Optionen vor oder nach den Fixture-Argumenten stehen.)

Zur Ausführung unter 1.2.3.4:7000 mit a Test Vorrichtung:

django-admin testserver --addrport 1.2.3.4:7000 test

Die --keine Eingabe Es kann eine Option bereitgestellt werden, um alle Benutzeraufforderungen zu unterdrücken.

bestätigen
django-admin bestätigen

Veraltet seit Version 1.7: Ersetzt durch aus der Ferne überprüfen Befehl.

Validiert alle installierten Modelle (gemäß INSTALLED_APPS Einstellung) und druckt
Validierungsfehler in die Standardausgabe umwandeln.

BEFEHLE UNTER DER VORAUSSETZUNG BY ANWENDUNGEN

Einige Befehle sind nur verfügbar, wenn die django.contrib Anwendung, die implementiert Sie
wurde freigegeben. In diesem Abschnitt werden sie nach ihrer Anwendung gruppiert beschrieben.

django.contrib.auth
Passwort ändern
django-admin Passwort ändern

Dieser Befehl ist nur verfügbar, wenn Django Beglaubigung fragst (django.contrib.auth) abgestimmt ist, lautet
installiert.

Ermöglicht das Ändern des Passworts eines Benutzers. Sie werden aufgefordert, das doppelte Passwort des Benutzers einzugeben
als Parameter angegeben. Stimmen beide überein, wird das neue Passwort sofort geändert. Wenn
Wenn Sie keinen Benutzer angeben, versucht der Befehl, das Kennwort zu ändern, dessen Benutzernamen verwendet wird
entspricht dem aktuellen Benutzer.

Verwenden Sie das --Datenbank Option zum Angeben der Datenbank, die für den Benutzer abgefragt werden soll. Wenn nicht
bereitgestellt, Django wird das verwenden Standard Datenbank.

Beispielverwendung:

Django-Admin Passwort ändern Ringo

erstelltsuperuser
django-admin erstelltsuperuser

Dieser Befehl ist nur verfügbar, wenn Django Beglaubigung fragst (django.contrib.auth) abgestimmt ist, lautet
installiert.

Erstellt ein Superuser-Konto (einen Benutzer, der über alle Berechtigungen verfügt). Dies ist bei Bedarf nützlich
um ein erstes Superuser-Konto zu erstellen oder wenn Sie es programmgesteuert generieren müssen
Superuser-Konten für Ihre Site(s).

Bei interaktiver Ausführung fordert dieser Befehl zur Eingabe eines Kennworts für den neuen Superuser auf
Konto. Bei nicht-interaktiver Ausführung wird kein Passwort und nur das Superuser-Konto festgelegt
Sie können sich erst anmelden, wenn manuell ein Passwort festgelegt wurde.

--Nutzername

--Email

Der Benutzername und die E-Mail-Adresse für das neue Konto können mithilfe von angegeben werden --Nutzername
und --Email Argumente in der Befehlszeile. Wenn eines davon nicht mitgeliefert wird,
erstelltsuperuser wird bei der interaktiven Ausführung dazu aufgefordert.

Verwenden Sie das --Datenbank Option zum Angeben der Datenbank, in der das Superuser-Objekt gespeichert werden soll
Gerettet.

Sie können den Verwaltungsbefehl unterordnen und überschreiben get_input_data() Wenn du möchtest
Passen Sie die Dateneingabe und -validierung an. Weitere Informationen zu den vorhandenen finden Sie im Quellcode
Implementierung und die Parameter der Methode. Es könnte beispielsweise nützlich sein, wenn Sie eine haben
Unbekannter Schlüssel in BENÖTIGTE FELDER und möchten das Erstellen einer Instanz anstelle der Eingabe zulassen
der Primärschlüssel einer vorhandenen Instanz.

django.contrib.gis
Ogrinspect
Dieser Befehl ist nur verfügbar, wenn GeoDjango (django.contrib.gis) ist installiert.

Bitte beachten Sie dessen Beschreibung in der GeoDjango-Dokumentation.

django.contrib.sessions
Clearsessions
django-admin Clearsessions

Kann als Cron-Job oder direkt ausgeführt werden, um abgelaufene Sitzungen zu bereinigen.

django.contrib.sitemaps
ping_google
Dieser Befehl ist nur verfügbar, wenn die Sitemaps Rahmen (django.contrib.sitemaps) abgestimmt ist, lautet
installiert.

Bitte beachten Sie dessen Beschreibung in der Sitemaps-Dokumentation.

django.contrib.staticfiles
Collectstatic
Dieser Befehl ist nur verfügbar, wenn die statisch Dateien Anwendung
(django.contrib.staticfiles) ist installiert.

Bitte beachten Sie dessen Beschreibung in England, statische Dateien Dokumentation.

findstatic
Dieser Befehl ist nur verfügbar, wenn die statisch Dateien Anwendung
(django.contrib.staticfiles) ist installiert.

Bitte beachten Sie dessen Beschreibung in England, statische Dateien Dokumentation.

DEFAULT OPTIONAL

Obwohl einige Befehle möglicherweise ihre eigenen benutzerdefinierten Optionen zulassen, ermöglicht jeder Befehl dies
folgende Optionen:

--pythonpath

Beispielverwendung:

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

Fügt den angegebenen Dateisystempfad zum Python hinzu importieren search Weg. Sollte dies nicht der Fall sein,
django-admin wird das benutzen PYTHONPFAD variable Umgebung

Beachten Sie, dass diese Option in nicht erforderlich ist manage.py, weil es sich um die Einstellung kümmert
Python-Pfad für Sie.

--die Einstellungen

Beispielverwendung:

django-admin migrate --settings=mysite.settings

Gibt explizit das zu verwendende Einstellungsmodul an. Das Einstellungsmodul sollte in Python sein
Paketsyntax, z mysite.settings. Sollte dies nicht der Fall sein, django-admin wird das benutzen
DJANGO_SETTINGS_MODULE variable Umgebung

Beachten Sie, dass diese Option in nicht erforderlich ist manage.py, weil es nutzt settings.py von dem
standardmäßig das aktuelle Projekt.

--zurück verfolgen

Beispielverwendung:

django-admin migrate --traceback

Standardmäßig django-admin zeigt eine einfache Fehlermeldung an, wenn ein CommandError tritt ein,
aber ein vollständiger Stack-Trace für jede andere Ausnahme. Wenn Sie angeben --zurück verfolgen, django-admin
gibt auch einen vollständigen Stack-Trace aus, wenn a CommandError angehoben wird.

--ausführlich

Beispielverwendung:

django-admin migrate --verbosity 2

Nutzen Sie --ausführlich um die Menge der Benachrichtigungs- und Debug-Informationen anzugeben
django-admin sollte auf der Konsole gedruckt werden.

· 0 bedeutet keine Ausgabe.

· 1 bedeutet normale Ausgabe (Standard).

· 2 bedeutet ausführliche Ausgabe.

· 3 Mittel verbinden sehr ausführliche Ausgabe.

--keine Farbe

Beispielverwendung:

django-admin sqlall --no-color

Standardmäßig django-admin formatiert die zu kolorierende Ausgabe. Zum Beispiel werden Fehler auftreten
werden in Rot auf der Konsole ausgegeben und SQL-Anweisungen werden syntaktisch hervorgehoben. Verhindern
this und haben Sie eine Klartextausgabe, übergeben Sie die --keine Farbe Option beim Ausführen Ihres Befehls.

COMMON OPTIONAL

Die folgenden Optionen sind nicht bei jedem Befehl verfügbar, sie gelten jedoch für eine bestimmte Zahl
von Befehlen.

--Datenbank

Wird verwendet, um die Datenbank anzugeben, auf der ein Befehl ausgeführt wird. Falls nicht angegeben, dies
Die Option verwendet standardmäßig einen Alias ​​von Standard.

Zum Beispiel, um Daten aus der Datenbank mit dem Alias ​​zu sichern führen zu:

django-admin dumpdata --database=master

--ausschließen

Schließen Sie eine bestimmte Anwendung aus den Anwendungen aus, deren Inhalte ausgegeben werden. Für
Beispiel, um das ausdrücklich auszuschließen auth Anwendung aus der Ausgabe von dumpdata, Sie
würde nennen:

django-admin dumpdata --exclude=auth

Wenn Sie mehrere Anwendungen ausschließen möchten, verwenden Sie mehrere --ausschließen Richtlinien:

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

- Gebietsschema

Verwenden Sie das - Gebietsschema or -l Option zum Angeben des zu verarbeitenden Gebietsschemas. Wenn nicht alles angegeben
Gebietsschemas werden verarbeitet.

--keine Eingabe

Verwenden Sie das --keine Eingabe Option zum Unterdrücken aller Benutzeraufforderungen, z. B. „Sind Sie sicher?“
Bestätigungsnachrichten. Dies ist nützlich, wenn django-admin wird unbeaufsichtigt ausgeführt,
automatisiertes Skript.

EXTRA Nettigkeiten

Syntax Färbung
Die django-admin / manage.py Die Befehle Ihres Terminals verwenden eine hübsche farbcodierte Ausgabe
unterstützt ANSI-farbige Ausgabe. Die Farbcodes werden nicht verwendet, wenn Sie die Befehle weiterleiten
Ausgabe an ein anderes Programm.

Unter Windows unterstützt die native Konsole daher standardmäßig keine ANSI-Escape-Sequenzen
Es erfolgt keine Farbausgabe. Aber Sie können das installieren ANSICON Drittanbieter-Tool, Django
Befehle erkennen seine Anwesenheit und nutzen seine Dienste, um die Ausgabe einfach zu färben
wie auf Unix-basierten Plattformen.

Die für die Syntaxhervorhebung verwendeten Farben können angepasst werden. Django wird mit drei Farben geliefert
Paletten:

· dunkel, geeignet für Terminals, die weißen Text auf schwarzem Hintergrund anzeigen. Dies ist das
Standardpalette.

· !, geeignet für Terminals, die schwarzen Text auf weißem Hintergrund anzeigen.

· keine Farbe, wodurch die Syntaxhervorhebung deaktiviert wird.

Sie wählen eine Palette aus, indem Sie a festlegen DJANGO_COLORS Umgebungsvariable zur Angabe der
Wählen Sie die Palette aus, die Sie verwenden möchten. Um beispielsweise die anzugeben ! Palette unter Unix oder OS/X
In der BASH-Shell würden Sie an einer Eingabeaufforderung Folgendes ausführen:

export DJANGO_COLORS="hell"

Sie können auch die verwendeten Farben anpassen. Django gibt eine Reihe von Rollen an
welche Farbe wird verwendet:

· Fehler - Ein schwerwiegender Fehler.

· beachten - Ein kleiner Fehler.

· sql_field – Der Name eines Modellfelds in SQL.

· sql_coltype – Der Typ eines Modellfelds in SQL.

· sql_keyword – Ein SQL-Schlüsselwort.

· sql_table – Der Name eines Modells in SQL.

· http_info – Eine 1XX-HTTP-Informationsserverantwort.

· http_success – Eine 2XX-HTTP-Erfolgsserverantwort.

· http_not_modified – Eine 304 HTTP Not Modified-Serverantwort.

· http_redirect – Eine andere 3XX-HTTP-Redirect-Serverantwort als 304.

· http_not_found – Eine 404 HTTP Not Found-Serverantwort.

· http_bad_request – Eine 4XX HTTP Bad Request-Serverantwort außer 404.

· http_server_error – Eine 5XX-HTTP-Serverfehlerantwort.

Jeder dieser Rollen kann eine bestimmte Vordergrund- und Hintergrundfarbe zugewiesen werden
folgende Liste:

· Schwarz

· rot markiert

· grünen

· gelben

· blauen

· Magenta

· Cyan

· Weiß

Jede dieser Farben kann dann mithilfe der folgenden Anzeigeoptionen geändert werden:

· fett

· unterstreichen

· blinken

· rückgängig machen

· verbergen

Eine Farbspezifikation folgt einem der folgenden Muster:

· Rolle=fg

· Rolle=fg/bg

· Rolle=fg,option,option

· Rolle=fg/bg,option,option

woher Rolle ist der Name einer gültigen Farbrolle, fg ist die Vordergrundfarbe, bg ist das
Hintergrundfarbe und jedes ganz ohne irgendetwas tun oder drücken zu müssen. ist eine der farbverändernden Optionen. Mehrere Farben
Die Angaben werden dann durch Semikolon getrennt. Zum Beispiel:

export DJANGO_COLORS="error=gelb/blau,blink;notice=magenta"

würde festlegen, dass Fehler durch blinkendes Gelb auf Blau und Hinweise angezeigt werden
in Magenta dargestellt. Alle anderen Farbrollen würden ungefärbt bleiben.

Farben können auch durch Erweitern einer Basispalette angegeben werden. Wenn Sie einen Palettennamen in a eingeben
Bei der Farbspezifikation werden alle von dieser Palette implizierten Farben geladen. Also:

export DJANGO_COLORS="light;error=gelb/blau,blink;notice=magenta"

würde die Verwendung aller Farben in der hellen Farbpalette spezifizieren, ausgeschlossen für die Farben
für Fehler und Hinweise, die wie angegeben außer Kraft gesetzt würden.

Unterstützung für farbcodierte Ausgabe von django-admin / manage.py Dienstprogramme unter Windows von
Die Verwendung der ANSICON-Anwendung wurde in Django 1.7 hinzugefügt.

Bash Abschluss
Wenn Sie die Bash-Shell verwenden, sollten Sie die Installation des Django-Bash-Vervollständigungsskripts in Betracht ziehen
lebt in extras/django_bash_completion in der Django-Distribution. Es ermöglicht
Tab-Vervollständigung von django-admin und manage.py Befehle, damit Sie zum Beispiel...

· Typ django-admin.

· Drücken Sie [TAB], um alle verfügbaren Optionen anzuzeigen.

· Typ SQL, dann [TAB], um alle verfügbaren Optionen anzuzeigen, deren Namen mit beginnen SQL.

Weitere Informationen finden Sie auch in den /howto/custom-management-commands Informationen zum Hinzufügen benutzerdefinierter Aktionen.

django.core.management.call_command(name, *Argumente, **Optionen)

Um einen Verwaltungsbefehl aus dem Code aufzurufen, verwenden Sie call_command.

Name der Name des aufzurufenden Befehls.

*Argumente eine Liste der vom Befehl akzeptierten Argumente.

**Optionen
benannte Optionen werden auf der Befehlszeile akzeptiert.

Beispiele:

aus der Importverwaltung von django.core
management.call_command('flush', ausführlichkeit=0, interaktiv=Falsch)
management.call_command('loaddata', 'test_data', verbosity=0)

Beachten Sie, dass Befehlsoptionen, die keine Argumente annehmen, als Schlüsselwörter mit übergeben werden richtig or
falsch, wie Sie mit dem sehen können interaktive Option oben.

Benannte Argumente können mit einer der folgenden Syntaxen übergeben werden:

# Ähnlich der Befehlszeile
management.call_command('dumpdata', '--natural-foreign')

# Benanntes Argument ähnlich der Befehlszeile abzüglich der anfänglichen Bindestriche und
# wobei interne Bindestriche durch Unterstriche ersetzt werden
management.call_command('dumpdata', natural_foreign=True)

# „use_natural_foreign_keys“ ist die Zielvariable der Option
management.call_command('dumpdata', use_natural_foreign_keys=True)

Die erste Syntax wird jetzt dank Verwaltungsbefehlen unterstützt, die die verwenden Argparse Modul.
Für die zweite Syntax hat Django den Optionsnamen jetzt unverändert an den Befehl übergeben
Es wird immer das verwendet dest Variablenname (der mit der Option identisch sein kann oder nicht).
Name).

Befehlsoptionen, die mehrere Optionen annehmen, werden in einer Liste übergeben:

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

AUSGABE UMLEITUNG

Beachten Sie, dass Sie Standardausgabe- und Fehlerströme umleiten können, da alle Befehle dies unterstützen
stdout und stderr Optionen. Du könntest zum Beispiel schreiben:

mit open('/tmp/command_output') as f:
management.call_command('dumpdata', stdout=f)

Verwenden Sie django-admin online über die Dienste von onworks.net