django-admin - Online în cloud

PROGRAM:

NUME

django-admin - Script utilitar pentru cadrul web Django

django-admin este utilitarul de linie de comandă al Django pentru sarcini administrative. Acest document
prezintă tot ce poate face.

Înainte de Django 1.7, django-admin a fost instalat doar ca django-admin.py.

În plus, gestionează.py este creat automat în fiecare proiect Django. gestionează.py este
înveliș subțire în jur django-admin care are grijă de mai multe lucruri pentru tine înainte
delegând la django-admin:

· Pune pachetul proiectului tău sys.path.

· Setează DJANGO_SETTINGS_MODULE variabilă de mediu astfel încât să indice către dvs
ale proiectului settings.py fișier.

· Apelează django.setup() pentru a inițializa diverse elemente interne ale Django.

django.setup() nu a existat în versiunile anterioare ale Django.

django-admin scriptul ar trebui să fie pe calea sistemului dumneavoastră dacă ați instalat Django prin intermediul acestuia
setup.py utilitate. Dacă nu este în calea ta, îl poți găsi în site-packages/django/bin
în cadrul instalării dvs. Python. Luați în considerare crearea unei legături simbolice dintr-un loc din calea dvs., de exemplu
as / / Local / bin usr.

Pentru utilizatorii Windows, care nu au disponibilă funcționalitate de legături simbolice, puteți copia
django-admin.exe într-o locație de pe calea dvs. existentă sau editați PATH setări (sub
Setări cont - Mod de control Panou - Sistem - Avansat - Mediu inconjurator...) pentru a indica instalat
locație.

În general, atunci când lucrați la un singur proiect Django, este mai ușor de utilizat gestionează.py decât
django-admin. Dacă trebuie să comutați între mai multe fișiere de setări Django, utilizați
django-admin cu DJANGO_SETTINGS_MODULE sau --setari opțiune linie de comandă.

Exemplele de linie de comandă din acest document folosesc django-admin a fi consecvent, dar
orice exemplu poate folosi gestionează.py la fel de bine.

UTILIZARE

$ django-admin [Opțiuni]
$ manage.py [Opțiuni]

comandă ar trebui să fie una dintre comenzile enumerate în acest document. Opțiuni, Care este
opțional, ar trebui să fie zero sau mai multe opțiuni disponibile pentru comanda dată.

Noțiuni de bază Runtime ajutor
django-admin ajutor

Alerga django-admin ajutor pentru a afișa informații de utilizare și o listă a comenzilor furnizate de
fiecare aplicație.

Alerga django-admin ajutor --comenzi pentru a afișa o listă cu toate comenzile disponibile.

Alerga django-admin ajutor pentru a afișa o descriere a comenzii date și o listă
dintre opțiunile sale disponibile.

Aplicaţia nume
Multe comenzi au o listă de „nume de aplicații”. Un „nume aplicație” este numele de bază al pachetului
care conțin modelele dvs. De exemplu, dacă dvs INSTALLED_APPS conţine şirul
„mysite.blog”, numele aplicației este blogul.

Determinarea il versiune
django-admin versiune

Alerga django-admin versiune pentru a afișa versiunea curentă Django.

Ieșirea urmează schema descrisă în PEP 386:

1.4.dev17026
1.4a1
1.4

Afiseaza depana producție
Utilizare --verbositate pentru a specifica cantitatea de informații de notificare și depanare care
django-admin ar trebui să imprime pe consolă. Pentru mai multe detalii, consultați documentația pentru
--verbositate opțiune.

DISPONIBIL COMANDE

verifica <nume aplicație numele aplicatiei ...>
django-admin verifica

Folosește sistem verifica cadru pentru a inspecta întregul proiect Django pentru probleme comune.

Cadrul de verificare a sistemului va confirma că nu există probleme cu instalarea dvs
modele sau înregistrările dvs. de administrator. De asemenea, va oferi avertismente privind compatibilitatea comună
probleme introduse de actualizarea Django la o versiune nouă. Pot fi introduse controale personalizate
de către alte biblioteci și aplicații.

În mod implicit, toate aplicațiile vor fi verificate. Puteți verifica un subset de aplicații furnizând o listă
a etichetelor aplicațiilor ca argumente:

python manage.py verifica autentificare admin myapp

Dacă nu specificați nicio aplicație, toate aplicațiile vor fi verificate.

--etichetă

sistem verifica cadru efectuează multe tipuri diferite de verificări. Aceste tipuri de cecuri sunt
clasificate cu etichete. Puteți folosi aceste etichete pentru a restricționa verificările efectuate la doar
cei dintr-o anumită categorie. De exemplu, pentru a efectua numai securitate și compatibilitate
verificări, ați rula:

python manage.py verificați --tag security --tag compatibilitatea

--list-etichete

Listați toate etichetele disponibile.

--desfășurați

--desfășurați opțiunea activează unele verificări suplimentare care sunt relevante doar în a
setarea de implementare.

Puteți utiliza această opțiune în mediul dvs. de dezvoltare locală, dar din punctul dvs. de vedere local
Modulul de setări de dezvoltare poate să nu aibă multe dintre setările dvs. de producție, veți avea
probabil vreau să punct verifica comandă la un alt modul de setări, fie prin setare
il DJANGO_SETTINGS_MODULE variabilă de mediu sau prin trecerea --setari opţiune:

python manage.py verifica --deploy --settings=production_settings

Sau îl puteți rula direct pe o implementare de producție sau de punere în pas pentru a verifica dacă
sunt în uz setările corecte (omițând --setari). Ai putea chiar să o faci parte din tine
suita de teste de integrare.

compila mesaje
django-admin compila mesaje

Compilează fișierele .po create de facemesaje în fișiere .mo pentru utilizare cu gettext încorporat
a sustine. Vedea /topics/i18n/index.

Folosește --locale opțiunea (sau versiunea sa mai scurtă -l) pentru a specifica locațiile de procesat.
Dacă nu sunt furnizate, toate localurile sunt procesate.

Folosește --exclude opțiunea (sau versiunea sa mai scurtă -x) pentru a specifica locația(urile) de exclus
de la prelucrare. Dacă nu sunt furnizate, nicio locație nu este exclusă.

Poți trece --utilizare-fuzzy opțiune (sau -f) pentru a include traduceri neclare în fișiere compilate.

Adăugat --exclude si --utilizare-fuzzy opțiuni.

Exemplu de utilizare:

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

createcachetable
django-admin createcachetable

Creează tabelele cache pentru a fi utilizate cu backend-ul cache al bazei de date. Vedea /topics/cache pentru
mai multe informatii.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pe care va fi stocarea cachetable
fi instalat.

Nu mai este necesar să furnizați numele tabelului cache sau --Bază de date opțiune. Django
preia aceste informații din fișierul dvs. de setări. Dacă ați configurat mai multe cache-uri sau
mai multe baze de date, toate tabelele cache sunt create.

dbshell
django-admin dbshell

Rulează clientul de linie de comandă pentru motorul bazei de date specificat în dvs MOTOR setare,
cu parametrii de conectare specificați în dvs USER, PAROLA, etc., setări.

· Pentru PostgreSQL, acesta rulează psql client de linie de comandă.

· Pentru MySQL, acesta rulează MySQL client de linie de comandă.

· Pentru SQLite, acesta rulează sqlite3 client de linie de comandă.

Această comandă presupune că programele sunt pe dvs PATH astfel încât un simplu apel la program
Nume (psql, MySQL, sqlite3) va găsi programul la locul potrivit. Nu există cum să
specificați manual locația programului.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pe care să deschideți un shell.

difsetări
django-admin difsetări

Afișează diferențele dintre fișierul de setări curent și setările implicite ale Django.

Setările care nu apar în setările implicite sunt urmate de "###". De exemplu, implicit
setările nu definesc ROOT_URLCONF, asa de ROOT_URLCONF este urmat de "###" în ieșirea de
difsetări.

--toate poate fi furnizată opțiunea pentru a afișa toate setările, chiar dacă au Django
valoare implicită. Astfel de setări sunt prefixate de "###".

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

Scoate la ieșire standard toate datele din baza de date asociate cu numele
aplicație(e).

Dacă nu este furnizat niciun nume de aplicație, toate aplicațiile instalate vor fi eliminate.

Rezultatul dumpdata poate fi folosit ca intrare pentru incarca date.

Rețineți că dumpdata folosește managerul implicit pe model pentru selectarea înregistrărilor către
haldă. Dacă utilizați un personalizat manager ca manager implicit și filtrează o parte din
înregistrările disponibile, nu toate obiectele vor fi aruncate.

--toate poate fi oferită opțiunea pentru a specifica faptul că dumpdata ar trebui să folosească baza lui Django
manager, înregistrări de dumping care altfel ar putea fi filtrate sau modificate de un obicei
administrator.

--format

În mod implicit, dumpdata își va formata rezultatul în JSON, dar puteți utiliza --format opțiune
pentru a specifica un alt format. Formatele acceptate în prezent sunt listate în
formate-serializare.

--liniuță

În mod implicit, dumpdata va scoate toate datele pe o singură linie. Acest lucru nu este ușor pentru oameni
citiți, astfel încât să puteți utiliza --liniuță opțiunea de a imprima destul de mult rezultatul cu un număr de
spații de indentare.

--exclude opțiunea poate fi furnizată pentru a preveni aplicații sau modele specifice (specificate
ca sub forma de app_label.ModelName) de a fi aruncat. Dacă specificați un nume de model pentru
dumpdata, ieșirea de dumping va fi limitată la acel model, mai degrabă decât la întreg
aplicarea. De asemenea, puteți combina numele aplicațiilor și numele modelelor.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date din care datele vor fi descărcate.

--natural-străin

Când este specificată această opțiune, Django va folosi cheie_naturală() metoda modelului de serializare
orice cheie străină și relație multi-la-mulți cu obiecte de tipul care definește
metodă. Dacă faci dumping contributie.auth permisiune obiecte sau contrib.contenttypes
Tipul de conținut obiecte, probabil că ar trebui să utilizați acest steag. Vezi natural chei
documentație pentru mai multe detalii despre aceasta și următoarea opțiune.

--natural-primar

Când este specificată această opțiune, Django nu va furniza cheia primară în serialul
datele acestui obiect deoarece poate fi calculat în timpul deserializării.

--natural

Depreciat de la versiunea 1.7: echivalent cu --natural-străin opțiune; folosește asta
in schimb.

Utilizare natural chei pentru a reprezenta orice cheie externă și relație multi-la-mulți cu un model
care oferă o definiție naturală a cheii.

--buc

În mod implicit, dumpdata va scoate toate înregistrările modelului, dar puteți utiliza --buc
opțiunea de a specifica o listă de chei primare separate prin virgulă pe care să se filtreze. Aceasta este numai
disponibil la dumpingul unui model.

--ieșire

În mod implicit dumpdata va scoate toate datele serializate la ieșire standard. Aceste opțiuni
permite specificarea fișierului în care urmează să fie scrise datele.

culoare
django-admin culoare

Îndepărtează toate datele din baza de date, reexecută orice gestionare de post-sincronizare și
reinstalează orice dispozitiv inițial de date.

--nicio intrare opțiunea poate fi furnizată pentru a suprima toate solicitările utilizatorului.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date de spălat.

--nicio-date-inițiale
Utilizare --nicio-date-inițiale pentru a evita încărcarea dispozitivului initial_data.

inspectdb
django-admin inspectdb

Introspectează tabelele și vizualizările bazei de date din baza de date indicată de NUME instalare
și emite un modul model Django (a modele.py fişier) la ieşirea standard.

Utilizați acest lucru dacă aveți o bază de date moștenită cu care doriți să utilizați Django. Scenariul
va inspecta baza de date și va crea un model pentru fiecare tabel sau vedere din cadrul acesteia.

După cum v-ați putea aștepta, modelele create vor avea un atribut pentru fiecare domeniu din
tabel sau vedere. Rețineți că inspectdb are câteva cazuri speciale în ieșirea numelui câmpului:

· Dacă inspectdb nu poate mapa tipul unei coloane la un tip de câmp model, va folosi TextField si
va insera comentariul Python 'Acest camp tip is a ghici.' lângă câmpul din
modelul generat.

· Dacă numele coloanei bazei de date este un cuvânt rezervat Python (cum ar fi 'trece', 'clasă' or
'pentru'), inspectdb va anexa '_camp' la numele atributului. De exemplu, dacă o masă
are o coloană 'pentru', modelul generat va avea un câmp 'for_field', Cu
db_coloană atribut setat la 'pentru'. inspectdb va insera comentariul Python 'Camp
redenumit deoarece it a fost a Piton rezervat cuvânt.' lângă câmp.

Această caracteristică este menită ca o comandă rapidă, nu ca generare definitivă de model. După ce îl rulezi,
veți dori să vă uitați singuri peste modelele generate pentru a face personalizări. În
în special, va trebui să rearanjați ordinea modelelor, astfel încât modelele care se referă la altele
modelele sunt comandate corect.

Cheile primare sunt introspectate automat pentru PostgreSQL, MySQL și SQLite, în care
cazul Django pune în primary_key=Adevărat acolo unde este nevoie.

inspectdb funcționează cu PostgreSQL, MySQL și SQLite. Detectarea cheii străine funcționează numai în
PostgreSQL și cu anumite tipuri de tabele MySQL.

Django nu creează valori implicite ale bazei de date atunci când a lipsă este specificat pe un câmp model.
În mod similar, valorile implicite ale bazei de date nu sunt traduse în valorile implicite ale câmpului de model sau detectate în niciuna
moda de inspectdb.

În mod implicit, inspectdb creează modele negestionate. Acesta este, gestionate = Fals în cel al modelului
meta clasa îi spune lui Django să nu gestioneze crearea, modificarea și ștergerea fiecărui tabel.
Dacă doriți să permiteți Django să gestioneze ciclul de viață al tabelului, va trebui să schimbați
gestionate opțiunea pentru Adevărat (sau pur și simplu eliminați-l pentru că Adevărat este valoarea sa implicită).

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date de introspectat.

A fost adăugată o funcție de inspectare a vizualizărilor bazei de date. În versiunile anterioare, numai tabele (nu
vederi) au fost inspectate.

incarca date <fixare accesoriu ...>
django-admin incarca date

Caută și încarcă conținutul dispozitivului numit în baza de date.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pe care se vor afla datele
încărcat.

--ignoreninexistent

--ignoreninexistent opțiunea poate fi folosită pentru a ignora câmpurile și modelele care ar fi putut fi
eliminat deoarece dispozitivul a fost generat inițial.

--aplicație

--aplicație opțiunea poate fi folosită pentru a specifica o singură aplicație în care să caute dispozitive în loc
caută prin toate aplicațiile.

--aplicație a fost adăugat.

--ignoreninexistent ignoră de asemenea modelele inexistente.

Ceea ce este a accesoriu ?
A accesoriu este o colecție de fișiere care conțin conținutul serializat al bazei de date.
Fiecare dispozitiv are un nume unic, iar fișierele care compun dispozitivul pot fi distribuite
peste mai multe directoare, în mai multe aplicații.

Django va căuta fix în trei locații:

1. În corpuri de iluminat directorul fiecărei aplicații instalate

2. În orice director numit în FIXTURE_DIRS instalare

3. În calea literală numită de dispozitiv

Django va încărca toate dispozitivele pe care le găsește în aceste locații care se potrivesc cu cele furnizate
nume de dispozitive.

Dacă dispozitivul numit are o extensie de fișier, vor fi încărcate numai corpurile de acest tip. Pentru
exemplu:

django-admin loaddata mydata.json

ar încărca doar dispozitivele JSON numite datele mele. Prelungirea dispozitivului trebuie să corespundă cu
numele înregistrat al a serializator (de exemplu, JSON or xml).

Dacă omiteți extensiile, Django va căuta toate tipurile de dispozitive disponibile pentru o potrivire
fixare. De exemplu:

django-admin loaddata mydata

ar căuta orice dispozitiv de orice tip de dispozitiv numit datele mele. Dacă un director de fixare
conținute mydata.json, acel dispozitiv va fi încărcat ca un dispozitiv JSON.

Fixările care sunt numite pot include componente de director. Aceste directoare vor fi
incluse în calea de căutare. De exemplu:

django-admin loaddata foo/bar/mydata.json

ar căuta /fixtures/foo/bar/mydata.json pentru fiecare aplicație instalată,
/foo/bar/mydata.json pentru fiecare director din FIXTURE_DIRS, și calea literală
foo/bar/mydata.json.

Când fișierele de fixare sunt procesate, datele sunt salvate în baza de date așa cum sunt. Model definit
salva() metode nu sunt numite, și orice pre_salvare or post_salvare semnalele vor fi apelate cu
brut=Adevărat deoarece instanța conține doar atribute care sunt locale modelului. Poți,
de exemplu, doriți să dezactivați gestionanții care accesează câmpuri asociate care nu sunt prezente
în timpul încărcării dispozitivului și altfel ar ridica o excepție:

din django.db.models.signals import post_save
din .modele import MyModel

def my_handler(**kwargs):
# dezactivați handler-ul în timpul încărcării dispozitivului
dacă kwargs['raw']:
reveni
...

post_save.connect(my_handler, sender=MyModel)

Ați putea, de asemenea, să scrieți un decorator simplu care să încapsuleze această logică:

din functools import wraps

def disable_for_loaddata(signal_handler):
"" "
Decorator care dezactivează dispozitivele de gestionare a semnalului la încărcarea datelor de fixare.
"" "
@wraps(signal_handler)
def wrapper(*args, **kwargs):
dacă kwargs['raw']:
reveni
signal_handler(*args, **kwargs)
ambalaj de returnare

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

Trebuie doar să știți că această logică va dezactiva semnalele ori de câte ori dispozitivele sunt deserializate,
nu doar în timpul incarca date.

Rețineți că ordinea în care fișierele fixture sunt procesate este nedefinită. Cu toate acestea, toate
Datele fixture sunt instalate ca o singură tranzacție, astfel încât datele dintr-un fix se pot referi
date într-un alt fix. Dacă backend-ul bazei de date acceptă constrângeri la nivel de rând, acestea
constrângerile vor fi verificate la sfârșitul tranzacției.

dumpdata comanda poate fi folosită pentru a genera intrare pentru incarca date.

comprimat corpuri de iluminat
Corpurile de iluminat pot fi comprimate zip, gz, bz2 format. De exemplu:

django-admin loaddata mydata.json

ar căuta oricare dintre mydata.json, mydata.json.zip, mydata.json.gz, mydata.json.bz2.
Se folosește primul fișier conținut într-o arhivă comprimată zip.

Rețineți că dacă sunt descoperite două corpuri de iluminat cu același nume, dar tip diferit de dispozitiv
(de exemplu, dacă mydata.json si mydata.xml.gz au fost găsite în același director de fixare),
instalarea dispozitivului va fi anulată și orice date instalate în apelul la incarca date voi
fi eliminat din baza de date.

MySQL cu MyISAM și fixtures

Motorul de stocare MyISAM al MySQL nu acceptă tranzacții sau constrângeri,
deci, dacă utilizați MyISAM, nu veți primi validarea datelor de fixare sau o restituire dacă
sunt găsite mai multe fișiere de tranzacție.

Specific bazei de date corpuri de iluminat
Dacă vă aflați într-o configurație cu mai multe baze de date, este posibil să aveți date de fixare pe care doriți să le încărcați
într-o bază de date, dar nu în alta. În această situație, puteți adăuga o bază de date
identificatorul în numele dispozitivelor dvs.

De exemplu, dacă dumneavoastră BAZELE DE DATE setarea are o bază de date „master” definită, denumește dispozitivul
mydata.master.json or mydata.master.json.gz iar dispozitivul va fi încărcat numai când dvs
specificați dacă doriți să încărcați date în maestru Bază de date.

facemesaje
django-admin facemesaje

Rulează peste întregul arbore sursă al directorului curent și scoate toate șirurile marcate
pentru traducere. Acesta creează (sau actualizează) un fișier de mesaj în conf/locale (în Django
arbore) sau directorul local (pentru proiect și aplicație). După efectuarea modificărilor la
fișierele de mesaje cu care trebuie să le compilați compila mesaje pentru utilizare cu sistemul încorporat
suport pentru gettext. Vezi i18n documentaţie pentru detalii.

--toate

Folosește --toate or -a opțiunea de a actualiza fișierele de mesaje pentru toate limbile disponibile.

Exemplu de utilizare:

django-admin makemessages --all

--extensie

Folosește --extensie or -e opțiunea de a specifica o listă de extensii de fișiere de examinat (implicit:
„.html”, „.txt”).

Exemplu de utilizare:

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

Separați mai multe extensii cu virgule sau utilizați -e sau --extension de mai multe ori:

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

Folosește --locale opțiunea (sau versiunea sa mai scurtă -l) pentru a specifica locațiile de procesat.

Folosește --exclude opțiunea (sau versiunea sa mai scurtă -x) pentru a specifica locația(urile) de exclus
de la prelucrare. Dacă nu sunt furnizate, nicio locație nu este exclusă.

Exemplu de utilizare:

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

A fost adăugat --anterior opțiune la msgmerge comandă la fuzionarea cu fișierele po existente.

--domeniu

Folosește --domeniu or -d opțiunea de a schimba domeniul fișierelor de mesaje. În prezent
sprijinit:

· django pentru toate *.py, *.html si * .txt fișiere (implicit)

· djangojs pentru *.js fișiere

--legături simbolice

Folosește --legături simbolice or -s opțiunea de a urma legăturile simbolice către directoare atunci când căutați noi
șiruri de traducere.

Exemplu de utilizare:

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

--ignora

Folosește --ignora or -i opțiunea de a ignora fișierele sau directoarele care se potrivesc cu cele date glob-Stil
model. Utilizați de mai multe ori pentru a ignora mai multe.

Aceste modele sunt utilizate în mod implicit: „CVS”, '.*', '*~', „*.pyc”

Exemplu de utilizare:

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

--no-default-ignore

Folosește --no-default-ignore opțiunea de a dezactiva valorile implicite ale --ignora.

--fără-înfășurare

Folosește --fără-înfășurare opțiunea de a dezactiva ruperea liniilor lungi de mesaje în mai multe rânduri în
fișiere de limbă.

--fără locație

Folosește --fără locație opțiunea de a nu scrie "#: nume de fișier:linie' linii de comentarii în limbă
fișiere. Rețineți că utilizarea acestei opțiuni îngreunează traducătorii calificați din punct de vedere tehnic
înțelege contextul fiecărui mesaj.

--ţine-oala

Folosește --ţine-oala opțiune pentru a preveni Django să șterge erorile temporare de depanare
ceea ce poate împiedica crearea fișierelor de limbă finală.

VEZI DE ASEMENEA:
Vedea personalizarea-realizarea mesajelor pentru instrucțiuni despre cum să personalizați cuvintele cheie care
facemesaje trece la xgettext.

face migrații [ ]
django-admin face migrații

Creează noi migrari pe baza modificărilor detectate la modelele dvs. Migrațiile, lor
relația cu aplicațiile și multe altele sunt tratate în profunzime în il migrațiune documentaţie.

Furnizarea unuia sau mai multor nume de aplicații ca argumente va limita migrațiile create la
aplicațiile specificate și orice dependențe necesare (tabelul de la celălalt capăt al a Cheie externă,
de exemplu).

--gol

--gol opțiunea va cauza face migrații pentru a scoate o migrare goală pentru
aplicații specificate, pentru editare manuală. Această opțiune este doar pentru utilizatorii avansați și nu ar trebui
poate fi utilizat cu excepția cazului în care sunteți familiarizat cu formatul de migrare, operațiunile de migrare și
dependențe dintre migrațiile dvs.

--funcție uscată

--funcție uscată opțiunea arată ce migrații ar fi făcute fără a scrie de fapt vreuna
migrarea fișierelor pe disc. Folosind această opțiune împreună cu --verbositate 3 va arăta de asemenea
fișiere complete de migrare care ar fi scrise.

--combina

--combina opțiunea permite remedierea conflictelor de migrare. The --nicio intrare opțiunea poate fi
furnizat pentru a suprima solicitările utilizatorului în timpul unei îmbinări.

--Nume, -n

--Nume opțiunea vă permite să dați migrației un nume personalizat în loc de unul generat
unul.

--Ieșire, -e

--Ieșire opțiunea va cauza face migrații pentru a ieși cu codul de eroare 1 când nu există migrare
sunt create (sau ar fi fost create, dacă ar fi fost combinate cu --funcție uscată).

migra [ [ ]]
django-admin migra

Sincronizează starea bazei de date cu setul curent de modele și migrări.
Migrațiile, relația lor cu aplicațiile și multe altele sunt tratate în profunzime il migrațiune
documentaţie.

Comportamentul acestei comenzi se modifică în funcție de argumentele furnizate:

· Fără argumente: Toate aplicațiile migrate au toate migrările rulate și toate nemigrate
aplicațiile sunt sincronizate cu baza de date,

· : Migrațiile din aplicația specificată sunt executate, până la cea mai recentă migrare.
Acest lucru poate implica rularea și migrarea altor aplicații, din cauza dependențelor.

· : Aduce schema bazei de date într-o stare în care este numită
se aplică migrarea, dar nu se aplică migrări ulterioare în aceeași aplicație. Acest lucru poate
implică neaplicarea migrărilor dacă ați migrat anterior peste migrarea numită.
Folosește numele zero pentru a anula toate migrările pentru o aplicație.

Spre deosebire de syncdb, această comandă nu vă solicită să creați un superutilizator dacă nu există unul
(presupunând că utilizați django.contrib.auth). Utilizare createsuperuser sa faci asta daca vrei.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date de migrat.

--fals

--fals opțiunea îi spune lui Django să marcheze migrațiile ca fiind aplicate sau neaplicate,
dar fără a rula efectiv SQL pentru a vă schimba schema bazei de date.

Acest lucru este destinat utilizatorilor avansați pentru a manipula starea actuală de migrare direct dacă
ei aplică manual modificările; fi avertizat că folosind --fals riscă să pună
tabelul de stare de migrare într-o stare în care va fi necesară recuperarea manuală
migrațiile rulează corect.

--fake-initial

--fake-initial opțiunea poate fi utilizată pentru a permite lui Django să omite migrarea inițială a unei aplicații
dacă toate tabelele de baze de date cu numele tuturor modelelor create de toți CreateModel operațiuni
în acea migrație există deja. Această opțiune este destinată utilizării la prima rulare
migrații față de o bază de date care a preexistat utilizării migrărilor. Această opțiune nu,
totuși, verificați dacă schema bazei de date se potrivește dincolo de numele de tabel potrivite și așa este
sigur de utilizat dacă sunteți sigur că schema dvs. existentă se potrivește cu ceea ce este înregistrat în
migrația dumneavoastră inițială.

Depreciat de la versiunea 1.8: The --listă opțiunea a fost mutată în showmigrations
comanda.

runfcgi [Opțiuni]
django-admin runfcgi

Depreciat de la versiunea 1.7: suportul FastCGI este depreciat și va fi eliminat în Django
1.9.

Pornește un set de procese FastCGI potrivite pentru utilizare cu orice server Web care acceptă
Protocolul FastCGI. Vezi FastCGI desfășurarea documentaţie pentru detalii. Necesită
Modulul Python FastCGI de la fugă.

Intern, aceasta include obiectul aplicației WSGI specificat de WSGI_APPLICATION
setare.

Opțiunile acceptate de această comandă sunt transmise bibliotecii FastCGI și nu folosesc
'--' prefix așa cum este de obicei pentru alte comenzi de management Django.

protocol

protocol=PROTOCOL

Protocol de utilizat. PROTOCOL poate fi fcgi, scgi, ajp, etc. (implicit este fcgi)

gazdă

gazdă=HOSTNAME

Nume de gazdă pentru a asculta.

port

port=PORTNUM

Port pentru a asculta.

priză

socket=FIȘIER

Socket UNIX pentru a asculta.

metodă

metoda=IMPL

Valori posibile: prefurcă or filetat (Mod implicit prefurcă)

maxcereri

maxrequests=NUMĂR

Numărul de solicitări pe care un copil le gestionează înainte de a fi ucis și a unui nou copil să fie transferat (0 înseamnă
fara limita).

maxspare

maxspare=NUMĂR

Număr maxim de procese / fire de rezervă.

minspare

minspare=NUMĂR

Număr minim de procese / fire de rezervă.

maxchildren

maxchildren=NUMĂR

Limită strictă a numărului de procese / fire.

daemonize

daemonize=BOOL

Dacă să se detașeze de la terminal.

pidfile

pidfile=FIȘIER

Scrieți codul de proces generat în fișier FILE.

workdir

workdir=DIRECTORY

Schimbați în director CATALOG când demonizează.

depana

depanare=BOOL

Setați la adevărat pentru a activa urmărirea falsului.

outlog

outlog=FIȘIER

Scrie stdout la FILE fișier.

eroare

errlog=FIȘIER

Scrieți stderr la FILE fișier.

masca

umask=UMASK

Umask de folosit la demonizare. Valoarea este interpretată ca un număr octal (valoare implicită
is 0o22).

Exemplu de utilizare:

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

Rulați un server FastCGI ca demon și scrieți PID-ul generat într-un fișier.

runserver [port or adresa:port]
django-admin runserver

Pornește un server Web de dezvoltare ușoară pe mașina locală. Implicit, serverul
rulează pe portul 8000 pe adresa IP 127.0.0.1. Puteți transmite o adresă IP și un port
număr în mod explicit.

Dacă rulați acest script ca utilizator cu privilegii normale (recomandat), este posibil să nu aveți
acces pentru a porni un port cu un număr de port scăzut. Numerele de porturi mici sunt rezervate pentru
superutilizator (rădăcină).

Acest server folosește obiectul aplicației WSGI specificat de WSGI_APPLICATION setare.

NU UTILIZAȚI ACEST SERVER ÎNTR-UN SETARE DE PRODUCȚIE. Nu a trecut prin audituri de securitate sau
teste de performanță. (Și așa va rămâne. Suntem în afacerea de a face web
cadre, nu servere Web, deci îmbunătățirea acestui server pentru a putea gestiona o producție
mediu este în afara domeniului de aplicare al Django.)

Serverul de dezvoltare reîncarcă automat codul Python pentru fiecare solicitare, după cum este necesar. Tu
nu este nevoie să reporniți serverul pentru ca modificările de cod să aibă efect. Cu toate acestea, unele acțiuni
cum ar fi adăugarea de fișiere, nu declanșează o repornire, așa că va trebui să reporniți serverul în acestea
cazuri.

Acum, compilarea fișierelor de traducere repornește și serverul de dezvoltare.

Dacă utilizați Linux și instalați pyinotify, semnalele nucleului vor fi folosite pentru a încărca automat
serverul (mai degrabă decât marcajele de timp pentru modificarea fișierului de interogare în fiecare secundă). Aceasta oferă
scalare mai bună la proiecte mari, reducerea timpului de răspuns la modificarea codului, mai mult
detectarea robustă a schimbărilor și reducerea utilizării bateriei.

pyinotify a fost adăugat suport.

Când porniți serverul și de fiecare dată când schimbați codul Python în timp ce serverul este
rulează, serverul va verifica întregul dvs. proiect Django pentru erori (vezi verifica
comanda). Dacă se găsesc erori, acestea vor fi tipărite la ieșire standard, dar nu va fi
opri serverul.

Puteți rula câte servere doriți, atâta timp cât sunt pe porturi separate. Doar
a executa django-admin runserver mai mult de o dată.

Rețineți că adresa IP implicită, 127.0.0.1, nu este accesibil de pe alte mașini de pe dvs
reţea. Pentru a face serverul de dezvoltare vizibil pentru alte mașini din rețea, utilizați
propria sa adresă IP (ex 192.168.2.1) Sau 0.0.0.0 or :: (cu IPv6 activat).

Puteți furniza o adresă IPv6 înconjurată de paranteze (de ex [200a::1]:8000). Asta va
activați automat suportul IPv6.

Un nume de gazdă care conține doar caractere ASCII poate fi, de asemenea, utilizat.

În cazul în care fisiere statice aplicația contrib este activată (implicit în proiectele noi) runserver comandă
va fi suprasolicitat cu propriile sale runserver comanda.

If migra nu a fost executat anterior, tabelul care stochează istoricul migrațiilor este
creat la prima rulare a runserver.

--noreload

Folosește --noreload opțiunea de a dezactiva utilizarea reîncărcării automate. Aceasta înseamnă orice Python
modificările de cod pe care le faceți în timp ce serverul rulează vor nu intră în vigoare dacă particularul
Modulele Python au fost deja încărcate în memorie.

Exemplu de utilizare:

django-admin runserver --noreload

--nothreading

Serverul de dezvoltare este implicit multithreaded. Folosește --nothreading opțiunea pentru
dezactivați utilizarea threading-ului în serverul de dezvoltare.

--ipv6, -6

Folosește --ipv6 (sau mai scurt -6) pentru a-i spune lui Django să folosească IPv6 pentru dezvoltare
Server. Aceasta schimbă adresa IP implicită de la 127.0.0.1 la ::1.

Exemplu de utilizare:

django-admin runserver --ipv6

Exemple of folosind diferit porturi si adrese
Portul 8000 pe adresa IP 127.0.0.1:

django-admin runserver

Portul 8000 pe adresa IP 1.2.3.4:

django-admin runserver 1.2.3.4:8000

Portul 7000 pe adresa IP 127.0.0.1:

django-admin runserver 7000

Portul 7000 pe adresa IP 1.2.3.4:

django-admin runserver 1.2.3.4:7000

Portul 8000 pe adresa IPv6 ::1:

django-admin runserver -6

Portul 7000 pe adresa IPv6 ::1:

django-admin runserver -6 7000

Portul 7000 pe adresa IPv6 2001:0db8:1234:5678::9:

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

Portul 8000 pe adresa IPv4 a gazdei localhost:

django-admin runserver localhost:8000

Portul 8000 pe adresa IPv6 a gazdei localhost:

django-admin runserver -6 localhost:8000

Servire static fișiere cu il dezvoltare serverul
În mod implicit, serverul de dezvoltare nu deservește fișiere statice pentru site-ul dvs. (cum ar fi
Fișiere CSS, imagini, lucruri de sub MEDIA_URL si asa mai departe). Dacă doriți să configurați Django
pentru a servi medii statice, citiți /howto/static-files/index.

coajă
django-admin coajă

Pornește interpretul interactiv Python.

Django va folosi IPython or bpython dacă oricare dintre ele este instalat. Dacă ai o coajă bogată
instalat, dar doriți să forțați utilizarea interpretului Python „plat”, utilizați --simplu opțiune,
ca astfel:

django-admin shell --plain

Dacă doriți să specificați fie IPython, fie bpython ca interpret, dacă aveți
ambele instalate, puteți specifica o interfață de interpret alternativ cu -i or
--interfață opțiuni de genul:

IPython:

django-admin shell -i ipython
django-admin shell --interface ipython

bpython:

django-admin shell -i bpython
django-admin shell --interface bpython

Când pornește interpretul interactiv Python „plat” (fie și pentru că --simplu a fost
specificat sau pentru că nu este disponibilă nicio altă interfață interactivă) citește scriptul
indicat de către PYTHONSTARTUP variabila de mediu si ~/.pythonrc.py scenariu. daca tu
nu doriți ca acest comportament să puteți utiliza --nu-pornire opțiune. de exemplu:

django-admin shell --plain --no-startup

showmigrations [ [ ]]
django-admin showmigrations

Afișează toate migrările dintr-un proiect.

--listă, -l

--listă opțiunea listează toate aplicațiile despre care Django știe, migrațiile disponibile pentru
fiecare aplicație și dacă fiecare migrație este aplicată sau nu (marcată cu un [X] Alături de
numele migrației).

Sunt listate și aplicațiile fără migrare, dar au (nu migrații) imprimat sub ele.

--plan, -p

--plan opțiunea arată planul de migrare pe care Django îl va urma pentru a aplica migrațiile. Orice
etichetele aplicațiilor furnizate sunt ignorate, deoarece planul ar putea depăși acele aplicații. La fel ca
--listă, migrațiile aplicate sunt marcate de un [X]. Pentru o verbozitate de 2 și mai sus, toate
dependențele unei migrări vor fi, de asemenea, afișate.

sql <app_label app_label ...>
django-admin sql

Tipărește instrucțiunile SQL CREATE TABLE pentru numele aplicației date.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care să imprimați SQL-ul.

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

Tipărește instrucțiunile CREATE TABLE și datele inițiale SQL pentru numele aplicației date.

Consultați descrierea sqlcustom pentru o explicație a modului de specificare a datelor inițiale.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care să imprimați SQL-ul.

sql* comenzile de management respectă acum allow_migrate() Metodă de DATABASE_ROUTERS.
Dacă aveți modele sincronizate cu baze de date non-implicite, utilizați --Bază de date flag pentru a obține SQL pentru
acele modele (anterior erau întotdeauna incluse în rezultat).

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

Tipărește instrucțiunile SQL DROP TABLE pentru numele aplicației date.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care să imprimați SQL-ul.

sqlcustom <app_label app_label ...>
django-admin sqlcustom

Tipărește instrucțiunile SQL personalizate pentru numele aplicației date.

Pentru fiecare model din fiecare aplicație specificată, această comandă caută fișierul
/sql/ .sql, În cazul în care este numele aplicației date și
este numele modelului cu litere mici. De exemplu, dacă aveți o aplicație ştiri care include un
Poveste model, sqlcustom va încerca să citească un fișier știri/sql/story.sql și atașați-l la
ieșirea acestei comenzi.

Fiecare dintre fișierele SQL, dacă este dat, este de așteptat să conțină SQL valid. Fișierele SQL sunt canalizate
direct în baza de date după ce toate declarațiile de creare a tabelelor din modele au fost
executat. Utilizați acest cârlig SQL pentru a face orice modificări ale tabelului sau pentru a introduce orice funcție SQL
în baza de date.

Rețineți că ordinea în care sunt procesate fișierele SQL este nedefinită.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care să imprimați SQL-ul.

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

Tipărește instrucțiunile SQL DROP INDEX pentru numele aplicației date.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care să imprimați SQL-ul.

sqlflush
django-admin sqlflush

Tipărește instrucțiunile SQL care ar fi executate pentru culoare comanda.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care să imprimați SQL-ul.

sqlindexes <app_label app_label ...>
django-admin sqlindexes

Tipărește instrucțiunile SQL CREATE INDEX pentru numele aplicației date.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care să imprimați SQL-ul.

sqlmigrate
django-admin sqlmigrate

Tipărește SQL-ul pentru migrarea numită. Acest lucru necesită o conexiune activă la baza de date, care
va folosi pentru a rezolva numele de constrângeri; aceasta înseamnă că trebuie să generați SQL împotriva unui
copie a bazei de date pe care doriți să o aplicați ulterior.

Rețineți că sqlmigrate nu își colorează rezultatul.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care se va genera SQL.

--înapoi

În mod implicit, SQL-ul creat este pentru rularea migrației în direcția înainte. Trece
--înapoi pentru a genera SQL-ul pentru anularea migrării.

sqlsequencereset <app_label app_label ...>
django-admin sqlsequencereset

Tipărește instrucțiunile SQL pentru resetarea secvențelor pentru numele aplicației date.

Secvențele sunt indecși utilizați de unele motoare de baze de date pentru a urmări următorul număr disponibil pentru
câmpuri incrementate automat.

Utilizați această comandă pentru a genera SQL care va rezolva cazurile în care o secvență nu este sincronizată cu
datele de câmp incrementate automat.

--Bază de date opțiunea poate fi utilizată pentru a specifica baza de date pentru care să imprimați SQL-ul.

migrații de dovleac
django-admin migrații de dovleac

Squashs migratiile pentru app_label Pana la, inclusiv nume_migrație jos în mai puține
migrații, dacă este posibil. Migrațiile zdrobite rezultate pot trăi alături de
cei nestriviți în siguranță. Pentru mai multe informații, vă rugăm să citiți migraţie-strivire.

--no-optimize

În mod implicit, Django va încerca să optimizeze operațiunile din migrațiile dvs. pentru a reduce
dimensiunea fișierului rezultat. Trece --no-optimize dacă acest proces eșuează pentru dvs. sau
creând migrații incorecte, deși vă rugăm să trimiteți și un raport de eroare Django despre
comportament, deoarece optimizarea este menită să fie sigură.

startapp [destinaţie]
django-admin startapp

Creează o structură de directoare a aplicației Django pentru numele aplicației date în directorul curent
sau destinația dată.

În mod implicit, directorul creat conține a modele.py fișier și alte fișiere șablon de aplicație.
(Vezi sursă pentru mai multe detalii.) Dacă este dat doar numele aplicației, directorul aplicației o va face
fi creat în directorul de lucru curent.

Dacă este furnizată destinația opțională, Django va folosi mai degrabă acel director existent
decât crearea unuia nou. Poți să folosești '.' pentru a indica directorul de lucru curent.

De exemplu:

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

--șablon

Cu --șablon opțiunea, puteți utiliza un șablon de aplicație personalizat, furnizând fie calea
la un director cu fișierul șablon de aplicație sau o cale către un fișier comprimat (.tar.gz,
.tar.bz2, . Tgz, .tbz, .zip) care conține fișierele șablon de aplicație.

De exemplu, acesta ar căuta un șablon de aplicație în directorul dat la crearea
aplicația mea app:

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

Django va accepta, de asemenea, URL-uri (http, https, ftp) la arhivele comprimate cu aplicația
fișiere șablon, descarcând și extragându-le din mers.

De exemplu, profitând de caracteristica Github pentru a expune depozitele ca fișiere zip, tu
poate folosi o adresă URL ca:

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

Când Django copie fișierele șablon de aplicație, redă și anumite fișiere prin intermediul
motor de șablon: fișierele ale căror extensii se potrivesc cu --extensie opțiune (py în mod implicit)
și fișierele ale căror nume sunt transmise cu --Nume opțiune. șablon context folosit este:

· Orice opțiune trecută către startapp comandă (printre opțiunile acceptate ale comenzii)

· numele aplicatiei -- numele aplicației așa cum a fost transmis comenzii

· directorul_aplicații -- calea completă a aplicației nou create

· docs_version -- versiunea documentației: „dev” or „1.x”

AVERTISMENT:
Când fișierele șablon de aplicație sunt redate cu motorul de șabloane Django (în mod implicit
toate *.py fișiere), Django va înlocui, de asemenea, toate variabilele șablon nevăzute conținute. Pentru
de exemplu, dacă unul dintre fișierele Python conține un șir de documente care explică un anumit
caracteristică legată de redarea șablonului, ar putea duce la un exemplu incorect.

Pentru a rezolva această problemă, puteți utiliza etichetă șablon templatetag pentru a „scăpa” de
diferite părți ale sintaxei șablonului.

startproject [destinaţie]
django-admin startproject

Creează o structură de director de proiect Django pentru numele proiectului dat în actualul
director sau destinația dată.

În mod implicit, noul director conține gestionează.py și un pachet de proiect (conținând un
settings.py și alte fișiere). Vezi șablon sursă pentru detalii.

Dacă este dat doar numele proiectului, vor fi atât directorul proiectului, cât și pachetul de proiect
numit iar directorul de proiect va fi creat în lucrul curent
director.

Dacă este furnizată destinația opțională, Django va folosi acel director existent ca
directorul de proiect și creați gestionează.py și pachetul de proiect din cadrul acestuia. Utilizare '.' la
indică directorul de lucru curent.

De exemplu:

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

Ca și în cazul startapp comanda, --șablon opțiunea vă permite să specificați un director, fișier
calea sau adresa URL a unui șablon de proiect personalizat. Vezi startapp documentație pentru detalii despre
formate de șablon de proiect acceptate.

De exemplu, acesta ar căuta un șablon de proiect în directorul dat la creare
il proiectul meu proiect:

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

Django va accepta, de asemenea, URL-uri (http, https, ftp) la arhivele comprimate cu proiectul
fișiere șablon, descarcând și extragându-le din mers.

De exemplu, profitând de caracteristica Github pentru a expune depozitele ca fișiere zip, tu
poate folosi o adresă URL ca:

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

Când Django copiază fișierele șablon de proiect, redă și anumite fișiere prin intermediul
motor de șablon: fișierele ale căror extensii se potrivesc cu --extensie opțiune (py în mod implicit)
și fișierele ale căror nume sunt transmise cu --Nume opțiune. șablon context folosit este:

· Orice opțiune trecută către startproject comandă (printre opțiunile acceptate ale comenzii)

· Denumirea proiectului -- numele proiectului așa cum a fost transmis comenzii

· director_proiect -- calea completă a proiectului nou creat

· cheie secreta -- o cheie aleatorie pentru CHEIE SECRETA instalare

· docs_version -- versiunea documentației: „dev” or „1.x”

Vă rugăm să vedeți și tencuială de avertizare după cum s-a menționat pentru startapp.

syncdb
django-admin syncdb

Depreciat de la versiunea 1.7: Această comandă a fost depreciată în favoarea migra
comandă, care efectuează atât comportamentul vechi, cât și migrarea. Este acum
doar un alias al acelei comenzi.

Alias ​​pentru migra.

test <aplicație or test identificator>
django-admin test

Efectuează teste pentru toate modelele instalate. Vedea /topics/testing/index pentru mai multe informatii.

--failfast

--failfast opțiunea poate fi utilizată pentru a opri rularea testelor și pentru a raporta imediat eșecul
după ce un test eșuează.

--testrunner

--testrunner opțiunea poate fi utilizată pentru a controla clasa de alergător de testare cu care este obișnuită
executa teste. Dacă această valoare este furnizată, ea înlocuiește valoarea furnizată de
TEST_RUNNER setare.

--liveserver

--liveserver opțiunea poate fi utilizată pentru a suprascrie adresa implicită unde serverul live
(utilizat cu LiveServerTestCase) este de așteptat să fugă de la. Valoarea implicită este
localhost: 8081.

--keepdb

--keepdb opțiunea poate fi utilizată pentru a păstra baza de date de testare între rulările de testare. Aceasta are
avantajul de a omite atât acțiunile de creare, cât și de distrugere, ceea ce scade foarte mult
timp pentru a rula teste, în special cele dintr-o suită mare de teste. Dacă baza de date de testare nu
există, va fi creat la prima rulare și apoi păstrat pentru fiecare rulare ulterioară. Orice
migrațiile neaplicate vor fi aplicate și bazei de date de testare înainte de a rula testul
pe.

--verso

--verso opțiunea poate fi folosită pentru a sorta cazurile de testare în ordine inversă. Acest lucru poate ajuta
în teste de depanare care nu sunt izolate corespunzător și au efecte secundare. Gruparea by test
clasă este păstrat atunci când utilizați această opțiune.

--debug-sql

--debug-sql opțiunea poate fi folosită pentru activare SQL logare pentru teste eșuate. Dacă --verbositate
is 2, apoi interogările în testele de trecere sunt de asemenea scoase.

server de testare <fixare accesoriu ...>
django-admin server de testare

Rulează un server de dezvoltare Django (ca în runserver) folosind date de la dispozitivul(ele) dat(e).

De exemplu, această comandă:

django-admin testserver mydata.json

...ar efectua următorii pași:

1. Creați o bază de date de testare, așa cum este descris în baza-de-date-test.

2. Completați baza de date de testare cu date de fixare de la dispozitivele date. (Pentru mai multe despre
accesorii, consultați documentația pentru incarca date de mai sus.)

3. Rulează serverul de dezvoltare Django (ca în runserver), a subliniat acest nou creat
baza de date de testare în locul bazei de date de producție.

Acest lucru este util în mai multe moduri:

· Când scrii unitate teste despre cum se comportă vederile tale cu anumite date de fixare, poți
utilizare server de testare pentru a interacționa manual cu vizualizările dintr-un browser Web.

· Să presupunem că vă dezvoltați aplicația Django și aveți o copie „pristine” a unui
baza de date cu care doriți să interacționați. Vă puteți arunca baza de date într-un dispozitiv
(folosind dumpdata comanda, explicată mai sus), apoi utilizați server de testare pentru a vă rula Web-ul
aplicație cu acele date. Cu acest aranjament, ai flexibilitatea de a te încurca
să-ți îmbunătățești datele în orice fel, știind că orice modificări de date pe care le faci sunt doar ființe
realizat într-o bază de date de testare.

Rețineți că acest server o face nu detectează automat modificările aduse codului sursă Python (cum ar fi
runserver face). Totuși, detectează modificările aduse șabloanelor.

--adrport [port număr or ipaddr:port]

Utilizare --adrport pentru a specifica un alt port, sau o adresă IP și un port diferit de cel implicit al
127.0.0.1:8000. Această valoare urmează exact același format și servește exact la fel
funcţionează ca argument pentru runserver comanda.

Exemple:

Pentru a rula serverul de testare pe portul 7000 cu fixare1 si fixare2:

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

(Afirmațiile de mai sus sunt echivalente. Le includem pe ambele pentru a demonstra că
nu contează dacă opțiunile vin înainte sau după argumentele fix.)

Pentru a rula pe 1.2.3.4:7000 cu a test fixare:

django-admin testserver --addrport 1.2.3.4:7000 test

--nicio intrare opțiunea poate fi furnizată pentru a suprima toate solicitările utilizatorului.

valida
django-admin valida

Învechit de la versiunea 1.7: Înlocuit de verifica comanda.

Validează toate modelele instalate (conform INSTALLED_APPS setare) și printuri
erori de validare la ieșirea standard.

COMANDE OFERIT BY APLICATII

Unele comenzi sunt disponibile numai atunci când django.contrib aplicație care ustensile lor
a fost activat. Această secțiune le descrie grupate în funcție de aplicația lor.

django.contrib.auth
schimbați parola
django-admin schimbați parola

Această comandă este disponibilă numai dacă este Django autentificare sistem (django.contrib.auth) este
instalat.

Permite schimbarea parolei unui utilizator. Vă solicită să introduceți de două ori parola utilizatorului
dat ca parametru. Dacă ambele se potrivesc, noua parolă va fi schimbată imediat. Dacă
nu furnizați un utilizator, comanda va încerca să schimbe parola al cărei nume de utilizator
se potrivește cu utilizatorul curent.

Folosește --Bază de date opțiunea de a specifica baza de date de interogat pentru utilizator. Dacă nu este
furnizat, Django va folosi lipsă Bază de date.

Exemplu de utilizare:

django-admin schimbă parola ringo

createsuperuser
django-admin createsuperuser

Această comandă este disponibilă numai dacă este Django autentificare sistem (django.contrib.auth) este
instalat.

Creează un cont de superutilizator (un utilizator care are toate permisiunile). Acest lucru este util dacă aveți nevoie
pentru a crea un cont inițial de superutilizator sau dacă trebuie să generați programatic
conturi de superutilizator pentru site-urile dvs.

Când rulează interactiv, această comandă va solicita o parolă pentru noul superutilizator
cont. Când rulați în mod non-interactiv, nu va fi setată nicio parolă și contul de superutilizator
nu se va putea autentifica până când nu a fost setată manual o parolă pentru aceasta.

--nume de utilizator

--e-mail

Numele de utilizator și adresa de e-mail pentru noul cont pot fi furnizate utilizând --nume de utilizator
si --e-mail argumente pe linia de comandă. Dacă oricare dintre acestea nu este furnizat,
createsuperuser îl va solicita atunci când rulează interactiv.

Folosește --Bază de date opțiunea de a specifica baza de date în care va fi obiectul superutilizator
salvat.

Puteți subclasa comanda de management și o puteți modifica get_input_data() dacă dorești
personalizați introducerea și validarea datelor. Consultați codul sursă pentru detalii despre cel existent
implementarea și parametrii metodei. De exemplu, ar putea fi util dacă aveți un
Cheie externă in CÂMPURI OBLIGATORII și doriți să permiteți crearea unei instanțe în loc să introduceți
cheia primară a unei instanțe existente.

django.contrib.gis
ogrinspect
Această comandă este disponibilă numai dacă GeoDjango (django.contrib.gis) este instalat.

Vă rugăm să consultați descriere în documentația GeoDjango.

django.contrib.sessions
sesiuni clare
django-admin sesiuni clare

Poate fi rulat ca un job cron sau direct pentru a curăța sesiunile expirate.

django.contrib.sitemaps
ping_google
Această comandă este disponibilă numai dacă Sitemap cadru (django.contrib.sitemaps) este
instalat.

Vă rugăm să consultați descriere în documentația Sitemaps.

django.contrib.staticfiles
colectstatic
Această comandă este disponibilă numai dacă static fișiere cerere
(django.contrib.staticfiles) este instalat.

Vă rugăm să consultați descriere în fisiere statice documentație.

findstatic
Această comandă este disponibilă numai dacă static fișiere cerere
(django.contrib.staticfiles) este instalat.

Vă rugăm să consultați descriere în fisiere statice documentație.

DEFAULT OPŢIUNI

Deși unele comenzi pot permite propriile opțiuni personalizate, fiecare comandă permite
următoarele opțiuni:

--pythonpath

Exemplu de utilizare:

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

Adaugă calea sistemului de fișiere dată la Python import căutare cale. Dacă acest lucru nu este furnizat,
django-admin va folosi PYTHONPATH variabilă de mediu.

Rețineți că această opțiune nu este necesară în gestionează.py, deoarece se ocupă de setarea
Calea Python pentru tine.

--setari

Exemplu de utilizare:

django-admin migrate --settings=mysite.settings

Specifică în mod explicit modulul de setări de utilizat. Modulul de setări ar trebui să fie în Python
sintaxa pachetului, de ex mysite.settings. Dacă acest lucru nu este furnizat, django-admin va folosi
DJANGO_SETTINGS_MODULE variabilă de mediu.

Rețineți că această opțiune nu este necesară în gestionează.py, pentru că folosește settings.py de la
proiectul curent în mod implicit.

--traceback

Exemplu de utilizare:

django-admin migrate --traceback

În mod implicit, django-admin va afișa un simplu mesaj de eroare ori de câte ori un CommandError apare,
dar o urmărire completă pentru orice altă excepție. Dacă specificați --traceback, django-admin
va scoate, de asemenea, o urmărire a stivei complete atunci când a CommandError este crescut.

--verbositate

Exemplu de utilizare:

django-admin migrate --verbosity 2

Utilizare --verbositate pentru a specifica cantitatea de informații de notificare și depanare care
django-admin ar trebui să imprime pe consolă.

· 0 înseamnă lipsă de ieșire.

· 1 înseamnă ieșire normală (implicit).

· 2 înseamnă ieșire verbosă.

· 3 mijloace foarte ieșire verbosă.

--fara-culoare

Exemplu de utilizare:

django-admin sqlall --no-color

În mod implicit, django-admin va formata ieșirea pentru a fi colorată. De exemplu, erorile vor
fi tipărit pe consolă în roșu și instrucțiunile SQL vor fi evidențiate de sintaxă. A preveni
aceasta și au o ieșire de text simplu, treceți --fara-culoare opțiune când rulați comanda.

COMUNĂ OPŢIUNI

Următoarele opțiuni nu sunt disponibile pentru fiecare comandă, dar sunt comune unui număr
a comenzilor.

--Bază de date

Folosit pentru a specifica baza de date pe care va opera o comandă. Dacă nu este specificat, aceasta
opțiunea va fi implicit la un alias de lipsă.

De exemplu, pentru a descărca datele din baza de date cu alias maestru:

django-admin dumpdata --database=master

--exclude

Excludeți o anumită aplicație din aplicațiile al căror conținut este scos. Pentru
exemplu, pentru a exclude în mod specific auth aplicație de la ieșirea dumpdata, tu
aș suna:

django-admin dumpdata --exclude=auth

Dacă doriți să excludeți mai multe aplicații, utilizați mai multe --exclude directive:

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

--locale

Folosește --locale or -l opțiunea de a specifica locația de procesat. Dacă nu sunt furnizate toate
localurile sunt procesate.

--nicio intrare

Folosește --nicio intrare opțiunea de a suprima toate solicitările utilizatorului, cum ar fi „Ești sigur?”
mesaje de confirmare. Acest lucru este util dacă django-admin este executat ca nesupravegheat,
script automatizat.

EXTRA BUCĂȚII

Sintaxă colorare
django-admin / gestionează.py comenzile vor folosi o ieșire destul de codificată în culori dacă terminalul dvs
acceptă ieșire color ANSI. Nu va folosi codurile de culoare dacă le introduceți pe cele ale comenzii
ieșire către alt program.

Sub Windows, consola nativă nu acceptă secvențe de evadare ANSI, așa că implicit
nu există ieșire de culoare. Dar puteți instala ANSICON instrument terță parte, Django
comenzile îi vor detecta prezența și vor folosi serviciile sale pentru a ieși doar color
ca pe platformele bazate pe Unix.

Culorile utilizate pentru evidențierea sintaxei pot fi personalizate. Django se livrează cu trei culori
palete:

· întuneric, potrivit pentru terminalele care afișează text alb pe fundal negru. Acesta este
paleta implicită.

· ușoară, potrivit pentru terminalele care afișează text negru pe fundal alb.

· nocolor, care dezactivează evidențierea sintaxei.

Selectați o paletă setând a DJANGO_COLORS variabilă de mediu pentru a specifica
paleta pe care doriți să o utilizați. De exemplu, pentru a specifica ușoară paletă sub Unix sau OS/X
BASH shell, veți rula următoarele la un prompt de comandă:

export DJANGO_COLORS="light"

De asemenea, puteți personaliza culorile folosite. Django specifică un număr de roluri în
ce culoare este folosita:

· eroare - O eroare majoră.

· a observa - O eroare minoră.

· câmp_sql - Numele unui câmp model în SQL.

· sql_coltype - Tipul unui câmp model în SQL.

· sql_keyword - Un cuvânt cheie SQL.

· tabel_sql - Numele unui model în SQL.

· http_info - Un răspuns de server 1XX HTTP Informational.

· http_succes - Un răspuns de server 2XX HTTP Success.

· http_ne_modificat - Un răspuns de server 304 HTTP nemodificat.

· http_redirect - Un răspuns de server de redirecționare HTTP 3XX, altul decât 304.

· http_ne_găsit - Un răspuns de server 404 HTTP Not Found.

· http_bad_request - Un răspuns de server 4XX HTTP Bad Request, altul decât 404.

· http_server_error - Un răspuns 5XX HTTP Server Error.

Fiecăruia dintre aceste roluri i se poate atribui o anumită culoare de prim-plan și de fundal, din
urmatoarea lista:

· negru

· roșu

· verde

· galben

· albastru

· purpuriu

· cyan

· alb

Fiecare dintre aceste culori poate fi apoi modificată utilizând următoarele opțiuni de afișare:

·

· sublinia

· clipi din ochi

· inversa

· ascunde

O specificație de culoare urmează unul dintre următoarele modele:

· rol=fg

· rol=fg/bg

· rol=fg,opțiune,opțiune

· rol=fg/bg,opțiune,opțiune

Unde rol este numele unui rol de culoare valid, fg este culoarea primului plan, bg este
culoarea de fundal și fiecare opțiune este una dintre opțiunile de modificare a culorii. Culoare multiplă
specificațiile sunt apoi separate prin punct și virgulă. De exemplu:

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

ar specifica că erorile vor fi afișate folosind galben intermitent pe albastru și notificări
afișat folosind magenta. Toate celelalte roluri de culoare ar fi lăsate necolorate.

Culorile pot fi specificate și prin extinderea unei palete de bază. Dacă puneți un nume de paletă într-un
specificația culorii, toate culorile implicate de acea paletă vor fi încărcate. Asa de:

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

ar specifica utilizarea tuturor culorilor din paleta de culori deschise, cu excepția pentru culori
pentru erori și notificări care ar fi înlocuite conform specificațiilor.

Suport pentru ieșire cu coduri de culoare de la django-admin / gestionează.py utilitare pe Windows de
bazându-se pe aplicația ANSICON a fost adăugată în Django 1.7.

Bash completare
Dacă utilizați shell-ul Bash, luați în considerare instalarea scriptului de finalizare Django bash, care
traieste in extras/django_bash_completion în distribuția Django. Permite
fila-completare a django-admin si gestionează.py comenzi, astfel încât să puteți, de exemplu...

· Tip django-admin.

· Apăsați [TAB] pentru a vedea toate opțiunile disponibile.

· Tip sql, apoi [TAB], pentru a vedea toate opțiunile disponibile ale căror nume încep cu sql.

Vedea /howto/custom-management-commands pentru cum să adăugați acțiuni personalizate.

django.core.management.call_command(nume, *args, **Opțiuni)

Pentru a apela o comandă de management din utilizarea codului comanda_apel.

nume numele comenzii de apelat.

*args o listă de argumente acceptate de comandă.

**Opțiuni
opțiunile numite acceptate pe linia de comandă.

Exemple:

de la django.core import management
management.call_command('flush', verbosity=0, interactive=False)
management.call_command('loaddata', 'test_data', verbosity=0)

Rețineți că opțiunile de comandă care nu iau argumente sunt transmise ca cuvinte cheie cu Adevărat or
Fals, după cum puteți vedea cu interactiv opțiunea de mai sus.

Argumentele numite pot fi transmise utilizând oricare dintre următoarele sintaxe:

# Similar cu linia de comandă
management.call_command('dumpdata', '--natural-foreign')

# Argument numit similar cu linia de comandă minus liniuțele inițiale și
# cu liniuțe interne înlocuite cu liniuțe de subliniere
management.call_command('dumpdata', natural_foreign=True)

# `use_natural_foreign_keys` este variabila destinație a opțiunii
management.call_command('dumpdata', use_natural_foreign_keys=True)

Prima sintaxă este acum acceptată datorită comenzilor de gestionare care utilizează argparse modul.
Pentru a doua sintaxă, Django a transmis anterior comenzii numele opțiunii așa cum este, acum
folosește întotdeauna destinaţie numele variabilei (care poate fi sau nu același cu opțiunea
Nume).

Opțiunile de comandă care au mai multe opțiuni primesc o listă:

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

REZULTATE REDIRECȚIE

Rețineți că puteți redirecționa fluxurile de ieșire standard și de eroare, deoarece toate comenzile acceptă
stdout si stderr Opțiuni. De exemplu, ai putea scrie:

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

Utilizați django-admin online folosind serviciile onworks.net