Django 2.1 - django-admin and manage.py

django-admin और manage.py




django

django-admin और manage.py

django-admin प्रशासनिक कार्यों के लिए Django की कमांड-लाइन उपयोगिता है। यह दस्तावेज़ यह सब कर सकता है।

इसके अलावा, प्रत्येक Django प्रोजेक्ट में manage.py अपने आप manage.py है। manage.py django-admin के समान काम करता है लेकिन आपके लिए कुछ बातों का ध्यान रखता है:

  • यह आपके प्रोजेक्ट के पैकेज को sys.path पर sys.path
  • यह DJANGO_SETTINGS_MODULE परिवेश चर सेट करता है ताकि यह आपकी परियोजना की settings.py फ़ाइल में इंगित हो।

यदि आपने Django को इसकी setup.py उपयोगिता के माध्यम से स्थापित किया है तो django-admin स्क्रिप्ट आपके सिस्टम पथ पर होनी चाहिए। यदि यह आपके रास्ते पर नहीं है, तो आप इसे अपने पायथन इंस्टॉलेशन के भीतर site-packages/django/bin में पा सकते हैं। अपने पथ के किसी स्थान से इसे सम्‍मिलित करने पर विचार करें, जैसे /usr/local/bin

विंडोज उपयोगकर्ताओं के लिए, जिनके पास सहानुभूति कार्यक्षमता उपलब्ध नहीं है, आप django-admin.exe को अपने मौजूदा पथ पर किसी स्थान पर कॉपी कर सकते हैं या PATH सेटिंग्स ( Settings - Control Panel - System - Advanced - Environment... ) को इंगित करने के लिए संपादित कर सकते हैं इसके स्थापित स्थान पर।

आमतौर पर, एक एकल Django परियोजना पर काम करते समय, django-admin तुलना में इसे manage.py करना आसान होता है। यदि आपको कई Django सेटिंग्स फ़ाइलों के बीच स्विच करने की आवश्यकता है, तो --settings या --settings कमांड लाइन विकल्प के साथ django-admin उपयोग करें।

इस दस्तावेज़ में कमांड-लाइन उदाहरण django-admin का उपयोग सुसंगत करने के लिए करते हैं, लेकिन कोई भी उदाहरण प्रबंधन या python -m django का भी उपयोग कर सकता है।

प्रयोग

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

command इस दस्तावेज़ में सूचीबद्ध कमांडों में से एक होना चाहिए। options , जो वैकल्पिक है, दिए गए कमांड के लिए उपलब्ध विकल्पों में से शून्य या अधिक होना चाहिए।

रनटाइम सहायता प्राप्त करना

django-admin help

उपयोग की जानकारी और प्रत्येक एप्लिकेशन द्वारा प्रदान की गई कमांड की सूची प्रदर्शित django-admin help लिए django-admin help चलाने में django-admin help करें।

सभी उपलब्ध आदेशों की सूची प्रदर्शित करने के लिए django-admin help --commands चलाएं।

दिए गए आदेश का विवरण और इसके उपलब्ध विकल्पों की सूची प्रदर्शित करने के लिए django-admin help <command> चलाएं।

ऐप के नाम

कई कमांड "ऐप नामों" की एक सूची लेते हैं। एक "ऐप नाम" आपके मॉडल वाले पैकेज का आधार है। उदाहरण के लिए, यदि आपके INSTALLED_APPS में स्ट्रिंग 'mysite.blog' , तो ऐप का नाम blog

संस्करण का निर्धारण

django-admin version

वर्तमान Django संस्करण प्रदर्शित करने के लिए django-admin version चलाएँ।

आउटपुट PEP 440 में वर्णित स्कीमा का अनुसरण करता है:

1.4.dev17026
1.4a1
1.4

डिबग आउटपुट प्रदर्शित करना

उपयोग की जाने वाली सूचना और डीबग सूचना को निर्दिष्ट करने के लिए --verbosity का उपयोग करें जो django-admin कंसोल को प्रिंट करता है।

उपलब्ध आदेश

check

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

सामान्य समस्याओं के लिए संपूर्ण Django परियोजना का निरीक्षण करने के लिए सिस्टम चेक फ्रेमवर्क का उपयोग करता है।

डिफ़ॉल्ट रूप से, सभी ऐप्स की जाँच की जाएगी। आप तर्क के रूप में ऐप लेबल की एक सूची प्रदान करके ऐप्स के सबसेट की जाँच कर सकते हैं:

django-admin check auth admin myapp

यदि आप किसी ऐप को निर्दिष्ट नहीं करते हैं, तो सभी ऐप चेक किए जाएंगे।

--tag TAGS, -t TAGS

सिस्टम चेक फ्रेमवर्क कई अलग-अलग प्रकार के चेक करता है जो टैग के साथ वर्गीकृत होते हैं। आप इन टैगों का उपयोग किसी विशेष श्रेणी में उन लोगों को दिए गए चेक को प्रतिबंधित करने के लिए कर सकते हैं। उदाहरण के लिए, केवल मॉडल और संगतता जाँच करने के लिए, चलाएं:

django-admin check --tag models --tag compatibility
--list-tags

सभी उपलब्ध टैग सूचीबद्ध करता है।

--deploy

कुछ अतिरिक्त चेक सक्रिय करता है जो केवल एक परिनियोजन सेटिंग में प्रासंगिक होते हैं।

आप अपने स्थानीय विकास परिवेश में इस विकल्प का उपयोग कर सकते हैं, लेकिन चूंकि आपके स्थानीय विकास सेटिंग्स मॉड्यूल में आपकी कई उत्पादन सेटिंग्स नहीं हो सकती हैं, आप शायद एक अलग सेटिंग मॉड्यूल में check कमांड को इंगित करना चाहेंगे, या तो DJANGO_SETTINGS_MODULE पर्यावरण चर सेट करके, या पासिंग विकल्प द्वारा:

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

या आप इसे सीधे उत्पादन या स्टेजिंग परिनियोजन पर चला सकते हैं ताकि यह सत्यापित किया जा सके कि सही सेटिंग्स उपयोग में हैं ( --settings )। आप इसे अपने एकीकरण परीक्षण सूट का हिस्सा भी बना सकते हैं।

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

संदेश स्तर को निर्दिष्ट करता है जो कमांड को गैर-शून्य स्थिति के साथ बाहर निकलने का कारण होगा। डिफ़ॉल्ट ERROR

compilemessages

django-admin compilemessages

संकलन .po फ़ाइलें makemessages द्वारा बनाई गई .mo फ़ाइलों के लिए उपयोग के लिए अंतर्निहित gettext समर्थन के साथ। अंतर्राष्ट्रीयकरण और स्थानीयकरण देखें।

--locale LOCALE, -l LOCALE

प्रक्रिया के लिए स्थान (यों) को निर्दिष्ट करता है। यदि उपलब्ध नहीं कराया गया है, तो सभी स्थानों पर कार्रवाई की जाती है।

--exclude EXCLUDE, -x EXCLUDE

प्रसंस्करण से बाहर करने के लिए स्थान (एस) निर्दिष्ट करता है। यदि प्रदान नहीं किया जाता है, तो कोई भी स्थान बाहर नहीं रखा जाता है।

--use-fuzzy, -f

संकलित फाइलों में फजी अनुवाद शामिल हैं।

उदाहरण का उपयोग:

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

डेटाबेस कैश के साथ उपयोग के लिए कैश टेबल को आपकी सेटिंग फ़ाइल से जानकारी का उपयोग करके बनाता है। अधिक जानकारी के लिए Django के कैश ढांचे को देखें।

--database DATABASE

वह डेटाबेस निर्दिष्ट करता है जिसमें कैश टेबल बनाई जाएगी। डिफ़ॉल्ट default से default

--dry-run

SQL को प्रिंट करता है जो वास्तव में इसे चलाने के बिना चलाया जाएगा, इसलिए आप इसे कस्टमाइज़ कर सकते हैं या माइग्रेशन फ्रेमवर्क का उपयोग कर सकते हैं।

dbshell

django-admin dbshell

आपके इंजिन सेटिंग में निर्दिष्ट डेटाबेस इंजन के लिए कमांड लाइन क्लाइंट चलाता है, आपके USER , PASSWORD , आदि में निर्दिष्ट कनेक्शन मापदंडों के साथ सेटिंग्स।

  • PostgreSQL के लिए, यह psql कमांड-लाइन क्लाइंट चलाता है।
  • MySQL के लिए, यह mysql कमांड-लाइन क्लाइंट चलाता है।
  • SQLite के लिए, यह sqlite3 कमांड-लाइन क्लाइंट चलाता है।
  • Oracle के लिए, यह sqlplus कमांड-लाइन क्लाइंट चलाता है।

यह आदेश मानता है कि प्रोग्राम आपके PATH ताकि प्रोग्राम नाम ( psql , mysql , sqlite3 , sqlplus ) के लिए एक सरल कॉल सही जगह पर प्रोग्राम को मिल जाएगा। प्रोग्राम का स्थान मैन्युअल रूप से निर्दिष्ट करने का कोई तरीका नहीं है।

--database DATABASE

उस डेटाबेस को निर्दिष्ट करता है जिस पर शेल खोलना है। डिफ़ॉल्ट default से default

diffsettings

django-admin diffsettings

वर्तमान सेटिंग्स फ़ाइल और Django की डिफ़ॉल्ट सेटिंग्स (या --default द्वारा निर्दिष्ट अन्य सेटिंग्स फ़ाइल) के बीच अंतर प्रदर्शित करता है।

सेटिंग जो डिफॉल्ट में दिखाई नहीं देती हैं, उसके बाद "###" । उदाहरण के लिए, डिफ़ॉल्ट सेटिंग्स ROOT_URLCONF को परिभाषित नहीं करती हैं, इसलिए ROOT_URLCONF का ROOT_URLCONF के आउटपुट में "###" diffsettings

--all

सभी सेटिंग्स प्रदर्शित करता है, भले ही उनके पास Django का डिफ़ॉल्ट मूल्य हो। ऐसी सेटिंग्स "###" द्वारा उपसर्ग की जाती हैं।

--default MODULE

के खिलाफ वर्तमान सेटिंग्स की तुलना करने के लिए सेटिंग्स मॉड्यूल। Django की डिफ़ॉल्ट सेटिंग्स के खिलाफ तुलना करने के लिए खाली छोड़ दें।

--output {hash,unified}
Django 2.0 में नया:

आउटपुट स्वरूप निर्दिष्ट करता है। उपलब्ध मूल्य hash और unifiedhash डिफ़ॉल्ट मोड है जो ऊपर वर्णित आउटपुट को प्रदर्शित करता है। unified diff -u समान आउटपुट को प्रदर्शित करता है। डिफ़ॉल्ट सेटिंग्स माइनस साइन के साथ प्रीफ़िक्स की जाती हैं, उसके बाद प्लस साइन के साथ प्रीफ़िक्स की गई बदली हुई सेटिंग।

dumpdata

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

मानक डेटा के आउटपुट डेटाबेस में सभी डेटा नामित एप्लिकेशन (एस) से जुड़े होते हैं।

यदि कोई एप्लिकेशन नाम प्रदान नहीं किया गया है, तो सभी इंस्टॉल किए गए एप्लिकेशन डंप हो जाएंगे।

dumpdata आउटपुट को dumpdata इनपुट के रूप में उपयोग किया जा सकता है।

ध्यान दें कि dumpdata रिकॉर्ड को चुनने के लिए मॉडल पर डिफ़ॉल्ट प्रबंधक का उपयोग करता है। यदि आप एक कस्टम प्रबंधक को डिफ़ॉल्ट प्रबंधक के रूप में उपयोग कर रहे हैं और यह कुछ उपलब्ध रिकॉर्डों को फ़िल्टर करता है, तो सभी ऑब्जेक्ट्स को डंप नहीं किया जाएगा।

--all, -a

Django के आधार प्रबंधक का उपयोग करता है, डंपिंग रिकॉर्ड जो अन्यथा कस्टम प्रबंधक द्वारा फ़िल्टर या संशोधित किया जा सकता है।

--format FORMAT

आउटपुट के क्रमांकन प्रारूप को निर्दिष्ट करता है। JSON के लिए डिफ़ॉल्ट। समर्थित प्रारूप Serialization स्वरूपों में सूचीबद्ध हैं।

--indent INDENT

आउटपुट में उपयोग करने के लिए इंडेंटेशन रिक्त स्थान की संख्या निर्दिष्ट करता है। उन सभी के लिए डिफॉल्ट जो एकल लाइन पर सभी डेटा प्रदर्शित करता है।

--exclude EXCLUDE, -e EXCLUDE

विशिष्ट अनुप्रयोगों या मॉडलों को रोकता है (डंप किए जाने से app_label.ModelName के रूप में निर्दिष्ट)। यदि आप एक मॉडल का नाम निर्दिष्ट करते हैं, तो आउटपुट पूरे आवेदन के बजाय उस मॉडल तक ही सीमित रहेगा। आप एप्लिकेशन नाम और मॉडल नाम भी मिला सकते हैं।

यदि आप कई अनुप्रयोगों को बाहर करना चाहते हैं, तो - एक से अधिक बार पास करें:

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

डेटाबेस निर्दिष्ट करता है जिससे डेटा डंप किया जाएगा। डिफ़ॉल्ट default से default

--natural-foreign

किसी भी विदेशी कुंजी और कई-से-कई संबंधों को क्रमबद्ध करने के लिए natural_key() मॉडल विधि का उपयोग करता है जो विधि को परिभाषित करता है। यदि आप contrib.auth Permission ऑब्जेक्ट्स को डंप कर रहे हैं या contrib.contenttypes ContentType ऑब्जेक्ट्स, तो आपको संभवतः इस ध्वज का उपयोग करना चाहिए। इस और अगले विकल्प के बारे में अधिक जानकारी के लिए प्राकृतिक कुंजी दस्तावेज देखें।

--natural-primary

इस ऑब्जेक्ट के क्रमबद्ध डेटा में प्राथमिक कुंजी को ओमिट्स करता है क्योंकि यह डीरिएरलाइज़ेशन के दौरान गणना की जा सकती है।

--pks PRIMARY_KEYS

केवल कॉमा द्वारा निर्दिष्ट वस्तुओं को प्राथमिक कुंजी की सूची से अलग करता है। यह केवल एक मॉडल को डंप करने पर उपलब्ध है। डिफ़ॉल्ट रूप से, मॉडल के सभी रिकॉर्ड आउटपुट होते हैं।

--output OUTPUT, -o OUTPUT

निर्दिष्ट डेटा को लिखने के लिए एक फ़ाइल निर्दिष्ट करता है। डिफ़ॉल्ट रूप से, डेटा मानक आउटपुट पर जाता है।

जब यह विकल्प सेट होता है और --verbosity 0 (डिफ़ॉल्ट) से अधिक होता है, तो टर्मिनल में एक प्रगति बार दिखाया जाता है।

flush

django-admin flush

डेटाबेस से सभी डेटा को निकालता है और किसी भी पोस्ट-सिंक्रनाइज़ेशन हैंडलर को फिर से निष्पादित करता है। जिस तालिका में माइग्रेशन लागू किया गया है, उसे साफ नहीं किया गया है।

यदि आप एक खाली डेटाबेस से शुरू करते हैं और सभी माइग्रेशन को फिर से चलाते हैं, तो आपको डेटाबेस को छोड़ देना चाहिए और फिर से बनाना होगा और उसके बजाय migrate करना होगा।

--noinput, --no-input

सभी उपयोगकर्ता संकेतों को दबा देता है।

--database DATABASE

डेटाबेस को फ्लश करने के लिए निर्दिष्ट करता है। डिफ़ॉल्ट default से default

inspectdb

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

डेटाबेस में डेटाबेस तालिकाओं को NAME सेटिंग द्वारा इंगित किया गया है और मानक आउटपुट के लिए एक Django मॉडल मॉड्यूल (एक मॉडल models.py फ़ाइल) को आउटपुट करता है।

आप तर्क के रूप में उनके नामों को पास करके निरीक्षण करने के लिए कौन सी सारणी या विचार चुन सकते हैं। यदि कोई तर्क प्रदान नहीं किया जाता है, तो मॉडल केवल विचारों के लिए बनाए जाते हैं यदि --include-views विकल्प का उपयोग किया जाता है।

यदि आपके पास विरासत डेटाबेस है जिसके साथ आप Django का उपयोग करना चाहते हैं तो इसका उपयोग करें। स्क्रिप्ट डेटाबेस का निरीक्षण करेगी और उसके भीतर प्रत्येक तालिका के लिए एक मॉडल बनाएगी।

जैसा कि आप उम्मीद कर सकते हैं, बनाए गए मॉडल में तालिका में हर क्षेत्र के लिए एक विशेषता होगी। ध्यान दें कि inspectdb क्षेत्र में अपने क्षेत्र-नाम आउटपुट में कुछ विशेष मामले हैं:

  • अगर inspectdb एक कॉलम के प्रकार को मॉडल फ़ील्ड प्रकार पर मैप नहीं कर सकता है, तो वह TextField उपयोग करेगा और पायथन टिप्पणी को सम्मिलित करेगा 'This field type is a guess.' उत्पन्न मॉडल में क्षेत्र के बगल में। मान्यता प्राप्त क्षेत्र INSTALLED_APPS में सूचीबद्ध ऐप्स पर निर्भर हो सकते हैं। उदाहरण के लिए, django.contrib.postgres कई PostgreSQL-विशिष्ट फ़ील्ड प्रकारों के लिए मान्यता जोड़ता है।
  • यदि डेटाबेस कॉलम नाम एक पायथन आरक्षित शब्द है (जैसे 'pass' , 'class' या 'for' ), तो inspectdb '_field' को विशेषता नाम में जोड़ देगा। उदाहरण के लिए, यदि किसी तालिका में 'for' कॉलम है, तो उत्पन्न मॉडल में 'for_field' फ़ील्ड होगी, जिसमें db_column विशेषता 'for' to 'for' सेट की गई होगी। inspectdb पायथन टिप्पणी को सम्मिलित करेगा 'Field renamed because it was a Python reserved word.' मैदान के बगल में।

यह सुविधा एक शॉर्टकट के रूप में है, न कि निश्चित मॉडल पीढ़ी के रूप में। इसे चलाने के बाद, आप कस्टमाइज़ेशन बनाने के लिए स्वयं उत्पन्न मॉडलों को देखना चाहेंगे। विशेष रूप से, आपको मॉडल के क्रम को पुनर्व्यवस्थित करने की आवश्यकता होगी, ताकि अन्य मॉडलों को संदर्भित करने वाले मॉडल ठीक से ऑर्डर किए जाएं।

प्राथमिक कुंजियाँ स्वचालित रूप से PostgreSQL, MySQL और SQLite के लिए आत्मनिरीक्षित होती हैं, जिस स्थिति में Django primary_key=True जहाँ आवश्यकता होती है डालता है।

inspectdb PostgreSQL, MySQL और SQLite के साथ काम करता है। विदेशी-कुंजी का पता लगाने केवल PostgreSQL और कुछ प्रकार के MySQL तालिकाओं के साथ काम करता है।

जब कोई default किसी मॉडल फ़ील्ड पर निर्दिष्ट होता है, तो Django डेटाबेस डिफॉल्ट नहीं बनाता है। इसी तरह, डेटाबेस inspectdb को मॉडल फ़ील्ड inspectdb में अनुवादित नहीं किया जाता है या किसी भी फैशन में inspectdb द्वारा पता लगाया जाता है।

डिफ़ॉल्ट रूप से, inspectdb unmanaged मॉडल बनाता है। यही है, managed = False मॉडल के Meta क्लास में managed = False से Django को प्रत्येक तालिका के निर्माण, संशोधन और विलोपन का प्रबंधन नहीं करने के लिए कहता है। यदि आप Django को तालिका के जीवनचक्र को प्रबंधित करने की अनुमति देना चाहते हैं, तो आपको managed विकल्प को True बदलना होगा (या बस इसे हटा दें क्योंकि True इसका डिफ़ॉल्ट मान है)।

--database DATABASE

डेटाबेस को आत्मनिरीक्षण करने के लिए निर्दिष्ट करता है। डिफ़ॉल्ट default से default

--include-views
Django 2.1 में नया:

यदि यह विकल्प प्रदान किया जाता है, तो डेटाबेस दृश्य के लिए मॉडल भी बनाए जाते हैं।

loaddata

django-admin loaddata fixture [fixture ...]

डेटाबेस में नामित स्थिरता की सामग्री को खोजता है और लोड करता है।

--database DATABASE

उस डेटाबेस को निर्दिष्ट करता है जिसमें डेटा लोड किया जाएगा। डिफ़ॉल्ट default से default

--ignorenonexistent, -i

फ़ील्ड्स और मॉडल को अनदेखा करता है, जो मूल रूप से स्थिरता उत्पन्न होने के बाद हटा दिए गए थे।

--app APP_LABEL

सभी ऐप में देखने के बजाय जुड़नार देखने के लिए एक एकल ऐप निर्दिष्ट करता है।

--format FORMAT
Django 2.0 में नया:

स्टड से पढ़े गए जुड़नार के लिए क्रमांकन प्रारूप (जैसे, json या xml ) को निर्दिष्ट करता है।

--exclude EXCLUDE, -e EXCLUDE

दिए गए अनुप्रयोगों और / या मॉडल ( app_label या app_label.ModelName ) से जुड़नार लोड करने को app_label.ModelName । एक से अधिक ऐप या मॉडल को बाहर करने के लिए कई बार विकल्प का उपयोग करें।

"स्थिरता" क्या है?

एक फ़िक्चर फ़ाइलों का एक संग्रह है जिसमें डेटाबेस की क्रमबद्ध सामग्री होती है। प्रत्येक फ़िक्चर का एक विशिष्ट नाम होता है, और फ़िक्चर को शामिल करने वाली फ़ाइलों को एक से अधिक निर्देशिकाओं में, कई अनुप्रयोगों में वितरित किया जा सकता है।

Django जुड़नार के लिए तीन स्थानों में खोज करेंगे:

  1. प्रत्येक इंस्टॉल किए गए एप्लिकेशन की fixtures निर्देशिका में
  2. FIXTURE_DIRS सेटिंग में नामित किसी भी निर्देशिका में
  3. फ़िक्चर द्वारा नामित शाब्दिक पथ में

Django किसी भी और सभी फिक्स्चर को लोड करेगा जो इन स्थानों में पाता है जो प्रदान किए गए फ़िक्चर नामों से मेल खाते हैं।

यदि नामित स्थिरता में फ़ाइल एक्सटेंशन है, तो केवल उस प्रकार के जुड़नार लोड किए जाएंगे। उदाहरण के लिए:

django-admin loaddata mydata.json

केवल JSON जुड़नार को लोड करेगा जिसे mydata कहा जाता है। स्थिरता विस्तार एक सीरियलाइज़र (उदाहरण के लिए, json या xml ) के पंजीकृत नाम के अनुरूप होना चाहिए।

यदि आप एक्सटेंशन को छोड़ देते हैं, तो Django एक मिलान स्थिरता के लिए सभी उपलब्ध स्थिरता प्रकारों की खोज करेगा। उदाहरण के लिए:

django-admin loaddata mydata

mydata नामक किसी भी स्थिरता प्रकार के किसी भी स्थिरता की तलाश करेगा। यदि एक mydata.json डायरेक्टरी में mydata.json , तो उस mydata.json को JSON mydata.json रूप में लोड किया जाएगा।

जिन फिक्स्चर को नाम दिया गया है उनमें निर्देशिका घटक शामिल हो सकते हैं। इन निर्देशिकाओं को खोज पथ में शामिल किया जाएगा। उदाहरण के लिए:

django-admin loaddata foo/bar/mydata.json

<dirname>/foo/bar/mydata.json में प्रत्येक निर्देशिका के लिए <app_label>/fixtures/foo/bar/mydata.json , <dirname>/foo/bar/mydata.json में प्रत्येक निर्देशिका के लिए <dirname>/foo/bar/mydata.json और शाब्दिक पथ foo/bar/mydata.json

जब फ़िक्चर फ़ाइलों को संसाधित किया जाता है, तो डेटा डेटाबेस में सहेजा जाता है। मॉडल परिभाषित save() विधियों को नहीं कहा जाता है, और किसी भी pre_save या post_save संकेतों को raw=True साथ कहा जाएगा क्योंकि उदाहरण में केवल वे विशेषताएँ हैं जो मॉडल के लिए स्थानीय हैं। उदाहरण के लिए, आप हैंडलर को अक्षम करना चाहते हैं जो संबंधित क्षेत्रों तक पहुँच प्राप्त करता है जो स्थिरता लोडिंग के दौरान मौजूद नहीं होते हैं और अन्यथा अपवाद नहीं उठाएंगे:

from django.db.models.signals import post_save
from .models import MyModel

def my_handler(**kwargs):
    # disable the handler during fixture loading
    if kwargs['raw']:
        return
    ...

post_save.connect(my_handler, sender=MyModel)

आप इस तर्क को समझने के लिए एक साधारण डेकोरेटर भी लिख सकते हैं:

from functools import wraps

def disable_for_loaddata(signal_handler):
    """
    Decorator that turns off signal handlers when loading fixture data.
    """
    @wraps(signal_handler)
    def wrapper(*args, **kwargs):
        if kwargs['raw']:
            return
        signal_handler(*args, **kwargs)
    return wrapper

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

बस इस बात से अवगत रहें कि यह तर्क सिग्नल को निष्क्रिय कर देगा जब जुड़नार deserialized होते हैं, न कि केवल loaddata दौरान।

ध्यान दें कि जिस क्रम में फ़िक्चर फ़ाइलों को संसाधित किया जाता है वह अपरिभाषित है। हालाँकि, सभी फ़िक्चर डेटा को एकल लेनदेन के रूप में स्थापित किया जाता है, इसलिए एक फ़िक्चर में डेटा दूसरे फ़िक्चर में डेटा को संदर्भित कर सकता है। यदि डेटाबेस बैकएंड पंक्ति-स्तरीय बाधाओं का समर्थन करता है, तो इन बाधाओं को लेनदेन के अंत में जांचा जाएगा।

dumpdata कमांड का उपयोग loaddata लिए इनपुट उत्पन्न करने के लिए किया जा सकता है।

संकुचित जुड़नार

फिक्स्चर को zip , gz , या bz2 प्रारूप में संपीड़ित किया जा सकता है। उदाहरण के लिए:

django-admin loaddata mydata.json

mydata.json , mydata.json.zip , mydata.json.gz , या mydata.json.bz2 किसी की mydata.json mydata.json.bz2 । ज़िप-संपीड़ित संग्रह के भीतर मौजूद पहली फ़ाइल का उपयोग किया जाता है।

ध्यान दें कि यदि एक ही नाम के साथ दो जुड़नार लेकिन अलग-अलग स्थिरता प्रकार की खोज की जाती है (उदाहरण के लिए, यदि mydata.json और mydata.xml.gz एक ही स्थिरता निर्देशिका में पाए गए थे), स्थिरता स्थापना समाप्त हो जाएगी, और किसी भी डेटा को इसमें स्थापित किया जाएगा। डेटाबेस से loaddata को हटा दिया जाएगा।

MySQL MyISAM और जुड़नार के साथ

MySQL का MyISAM स्टोरेज इंजन लेन-देन या बाधाओं का समर्थन नहीं करता है, इसलिए यदि आप MyISAM का उपयोग करते हैं, तो आपको कई डेटा फ़ाइलों के मिलने पर फिक्सेशन डेटा, या रोलबैक का सत्यापन नहीं मिलेगा।

डेटाबेस-विशिष्ट फिक्स्चर

यदि आप एक बहु-डेटाबेस सेटअप में हैं, तो आपके पास स्थिरता डेटा हो सकता है जिसे आप एक डेटाबेस पर लोड करना चाहते हैं, लेकिन दूसरे पर नहीं। इस स्थिति में, आप अपने जुड़नार के नाम में एक डेटाबेस पहचानकर्ता जोड़ सकते हैं।

उदाहरण के लिए, यदि आपके DATABASES सेटिंग में 'मास्टर' डेटाबेस परिभाषित है, तो फ़िक्सचर mydata.master.json या mydata.master.json.gz नाम mydata.master.json.gz और mydata.master.json.gz केवल तभी लोड किया जाएगा जब आप निर्दिष्ट करेंगे कि आप master डेटाबेस में डेटा लोड करना चाहते हैं ।

stdin से जुड़नार लोड हो रहा है

Django 2.0 में नया:

आप sys.stdin से इनपुट लोड करने के लिए स्थिरता नाम के रूप में डैश का उपयोग कर सकते हैं। उदाहरण के लिए:

django-admin loaddata --format=json -

--format से पढ़ते समय, इनपुट के क्रमांकन प्रारूप (उदाहरण के लिए, json या xml ) को निर्दिष्ट करने के लिए --format विकल्प की आवश्यकता होती है।

stdin से लोडिंग मानक इनपुट और आउटपुट पुनर्निर्देशन के साथ उपयोगी है। उदाहरण के लिए:

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

makemessages

django-admin makemessages

वर्तमान निर्देशिका के पूरे स्रोत पेड़ पर चलता है और अनुवाद के लिए चिह्नित सभी तारों को बाहर निकालता है। यह कन्फ़ेक्शन / लोकेल (Django ट्री में) या लोकेल (प्रोजेक्ट और एप्लिकेशन के लिए) डायरेक्टरी में एक संदेश फ़ाइल (या अपडेट) बनाता है। संदेशों की फ़ाइलों में परिवर्तन करने के बाद, आपको उन्हें compilemessages समर्थन के साथ उपयोग के लिए संकलन के साथ संकलन करने की आवश्यकता है। विवरण के लिए i18n प्रलेखन देखें।

इस कमांड को कॉन्फ़िगर सेटिंग्स की आवश्यकता नहीं है। हालाँकि, जब सेटिंग्स कॉन्फ़िगर नहीं होती हैं, तो कमांड MEDIA_ROOT और STATIC_ROOT निर्देशिकाओं को अनदेखा नहीं कर सकता है या LOCALE_PATHS शामिल कर LOCALE_PATHS । यह FILE_CHARSET बजाय UTF-8 में फ़ाइलें भी FILE_CHARSET

--all, -a

सभी उपलब्ध भाषाओं के लिए संदेश फ़ाइलों को अपडेट करता है।

--extension EXTENSIONS, -e EXTENSIONS

जाँच करने के लिए फ़ाइल एक्सटेंशन की सूची निर्दिष्ट करता है (डिफ़ॉल्ट: html , txt , py या js यदि --domain js )।

उदाहरण का उपयोग:

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

कई एक्सटेंशन को अल्पविराम या उपयोग -e या --extension कई बार अलग-अलग करें:

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

प्रक्रिया के लिए स्थान (यों) को निर्दिष्ट करता है।

--exclude EXCLUDE, -x EXCLUDE

प्रसंस्करण से बाहर करने के लिए स्थान (एस) निर्दिष्ट करता है। यदि प्रदान नहीं किया जाता है, तो कोई भी स्थान बाहर नहीं रखा जाता है।

उदाहरण का उपयोग:

django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
--domain DOMAIN, -d DOMAIN

संदेश फ़ाइलों के डोमेन को निर्दिष्ट करता है। समर्थित विकल्प हैं:

  • सभी *.py , *.html और *.txt फ़ाइलों (डिफ़ॉल्ट) के लिए django
  • *.js फ़ाइलों के लिए djangojs

नए अनुवाद स्ट्रिंग्स की तलाश में निर्देशिकाओं के लिए सहानुभूति का अनुसरण करता है।

उदाहरण का उपयोग:

django-admin makemessages --locale=de --symlinks
--ignore PATTERN, -i PATTERN

दिए गए glob पैटर्न से मेल खाती फाइलों या निर्देशिकाओं को अनदेखा करता है। अधिक अनदेखा करने के लिए कई बार उपयोग करें।

ये पैटर्न डिफ़ॉल्ट रूप से उपयोग किए जाते हैं: 'CVS' , '.*' , '*~' , '*.pyc'

उदाहरण का उपयोग:

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

--Ignore के डिफ़ॉल्ट मानों को निष्क्रिय करता है।

--no-wrap

भाषा फ़ाइलों में लंबी संदेश लाइनों को तोड़ने में अक्षम करता है।

--no-location

भाषा की फाइलों में ' #: filename:line ' टिप्पणी लाइनें लिखने का दमन करता है। इस विकल्प का उपयोग तकनीकी रूप से कुशल अनुवादकों के लिए प्रत्येक संदेश के संदर्भ को समझना कठिन बनाता है।

--add-location [{full,file,never}]
Django 2.0 में नया:

नियंत्रण #: filename:line भाषा फ़ाइलों में #: filename:line टिप्पणी लाइनें। यदि विकल्प है:

  • full (डिफ़ॉल्ट यदि नहीं दिया गया है): लाइनों में फ़ाइल नाम और लाइन नंबर दोनों शामिल हैं।
  • file : लाइन नंबर छोड़ा गया है।
  • never : लाइनों को दबा दिया जाता है (जैसे --no-location )।

gettext 0.19 या नए की आवश्यकता है।

--keep-pot

.pot फ़ाइल बनाने से पहले उत्पन्न अस्थायी .pot फ़ाइलों को हटाने से रोकता है। यह डिबगिंग त्रुटियों के लिए उपयोगी है जो अंतिम भाषा फ़ाइलों को बनने से रोक सकती है।

यह भी देखें

उन निर्देशों को कैसे अनुकूलित करें, इसके लिए निर्देशन के लिए makemessages को अनुकूलित करना देखें कि makemessages पास करता है।

makemigrations

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

आपके मॉडल में पाए गए परिवर्तनों के आधार पर नए माइग्रेशन बनाता है। माइग्रेशन, ऐप्स और अधिक के साथ उनका संबंध माइग्रेशन प्रलेखन में गहराई से कवर किया गया है।

तर्कों के रूप में एक या एक से अधिक ऐप नाम प्रदान करना, ऐप (एस) के लिए बनाए गए माइग्रेशन को निर्दिष्ट करेगा और किसी भी निर्भरता की आवश्यकता होगी (उदाहरण के लिए, ForeignKey के दूसरे छोर पर तालिका)।

ऐसे ऐप में माइग्रेशन जोड़ने के लिए, जिसमें migrations डायरेक्टरी नहीं है, ऐप के app_label के साथ app_label

--noinput, --no-input

सभी उपयोगकर्ता संकेतों को दबा देता है। यदि एक दबा हुआ संकेत स्वचालित रूप से हल नहीं किया जा सकता है, तो कमांड त्रुटि कोड 3 से बाहर निकल जाएगी।

--empty

मैन्युअल संपादन के लिए, निर्दिष्ट एप्लिकेशन के लिए एक खाली माइग्रेशन आउटपुट। यह उन्नत उपयोगकर्ताओं के लिए है और इसका उपयोग तब तक नहीं किया जाना चाहिए जब तक कि आप माइग्रेशन फॉर्मेट, माइग्रेशन ऑपरेशंस और अपने माइग्रेशन के बीच निर्भरता से परिचित न हों।

--dry-run

दिखाता है कि वास्तव में डिस्क पर कोई भी माइग्रेशन फाइल लिखने के बिना माइग्रेशन क्या होगा। --verbosity 3 के साथ इस विकल्प का उपयोग करने से पूर्ण माइग्रेशन फ़ाइलें भी लिखी जाएंगी।

--merge

माइग्रेशन संघर्षों को ठीक करने में सक्षम करता है।

--name NAME, -n NAME

उत्पन्न नाम का उपयोग करने के बजाय उत्पन्न माइग्रेशन का नामकरण करने देता है।

--check

जब माइग्रेशन के बिना मॉडल परिवर्तन का पता लगाया जाता है, तो एक गैर-शून्य स्थिति के साथ makemigrations निकलता है।

migrate

django-admin migrate [app_label] [migration_name]

मॉडल और माइग्रेशन के वर्तमान सेट के साथ डेटाबेस स्थिति को सिंक्रनाइज़ करता है। माइग्रेशन, ऐप्स और अधिक के साथ उनका संबंध माइग्रेशन प्रलेखन में गहराई से कवर किया गया है।

इस आदेश का व्यवहार प्रदान किए गए तर्कों के आधार पर बदलता है:

  • कोई तर्क नहीं: सभी ऐप्स के सभी माइग्रेशन चलते हैं।
  • <app_label> : निर्दिष्ट ऐप के हाल के प्रवास तक, इसके माइग्रेशन चलते हैं। इसमें निर्भरता के कारण अन्य ऐप्स का माइग्रेशन भी शामिल हो सकता है।
  • <app_label> <migrationname> : डेटाबेस स्कीमा को एक ऐसी स्थिति में लाता है, जहाँ नामित माइग्रेशन लागू होता है, लेकिन बाद में उसी ऐप में माइग्रेशन लागू नहीं होते हैं। यदि आप पहले से नामांकित माइग्रेशन से पहले माइग्रेट कर चुके हैं तो इसमें अप्रयुक्त माइग्रेशन शामिल हो सकते हैं। ऐप के लिए सभी माइग्रेशन को अनप्लग करने के लिए zero नाम का उपयोग करें।
--database DATABASE

डेटाबेस को माइग्रेट करने के लिए निर्दिष्ट करता है। डिफ़ॉल्ट default से default

--fake

माइग्रेशन को एक के रूप में लक्ष्य एक (ऊपर के नियमों का पालन करते हुए) पर लागू किया जाता है, लेकिन वास्तव में आपके डेटाबेस स्कीमा को बदलने के लिए SQL चलाने के बिना।

यदि वे मैन्युअल रूप से परिवर्तन लागू कर रहे हैं, तो यह उन्नत उपयोगकर्ताओं के लिए वर्तमान माइग्रेशन स्थिति में सीधे हेरफेर करने के लिए है; चेतावनी दी जाती है कि उपयोग करने से - माइग्रेशन स्टेट टेबल को एक ऐसी स्थिति में रखने का जोखिम होता है जहां माइग्रेशन को सही ढंग से चलाने के लिए मैनुअल रिकवरी की आवश्यकता होगी।

--fake-initial

यदि सभी डेटाबेस तालिकाओं को उस माइग्रेशन में मौजूद सभी CreateModel ऑपरेशंस द्वारा बनाए गए सभी मॉडलों के नाम के साथ रखते हैं, तो Django किसी ऐप के शुरुआती माइग्रेशन को छोड़ देता है। यह विकल्प उपयोग के लिए अभिप्रेत है जब पहली बार माइग्रेशन के उपयोग को रोकने वाले डेटाबेस के खिलाफ माइग्रेशन चल रहा हो। यह विकल्प, हालांकि, मिलान तालिका नामों से परे मिलान डेटाबेस स्कीमा के लिए जाँच नहीं करता है और इसलिए यह उपयोग करने के लिए केवल सुरक्षित है यदि आपको विश्वास है कि आपका मौजूदा स्कीमा आपके प्रारंभिक माइग्रेशन में दर्ज है।

--run-syncdb

माइग्रेशन के बिना ऐप्स के लिए टेबल बनाने की अनुमति देता है। हालांकि इसकी अनुशंसा नहीं की जाती है, सैकड़ों मॉडल के साथ बड़ी परियोजनाओं पर कभी-कभी माइग्रेशन फ्रेमवर्क बहुत धीमा होता है।

--noinput, --no-input

सभी उपयोगकर्ता संकेतों को दबा देता है। एक उदाहरण संकेत बासी सामग्री प्रकारों को हटाने के बारे में पूछ रहा है।

runserver

django-admin runserver [addrport]

स्थानीय मशीन पर एक हल्का विकास वेब सर्वर शुरू करता है। डिफ़ॉल्ट रूप से, सर्वर IP पते 127.0.0.1 पर पोर्ट 8000 पर चलता है। आप आईपी पते और पोर्ट नंबर को स्पष्ट रूप से पास कर सकते हैं।

यदि आप इस स्क्रिप्ट को सामान्य विशेषाधिकारों (अनुशंसित) के साथ एक उपयोगकर्ता के रूप में चलाते हैं, तो आपके पास कम पोर्ट संख्या पर पोर्ट शुरू करने के लिए उपयोग नहीं हो सकता है। सुपर पोर्ट (रूट) के लिए कम पोर्ट नंबर आरक्षित हैं।

यह सर्वर WSGI_APPLICATION सेटिंग द्वारा निर्दिष्ट WSGI एप्लिकेशन ऑब्जेक्ट का उपयोग करता है।

एक उत्पादन सेटिंग में इस धारा का उपयोग न करें। यह सुरक्षा ऑडिट या प्रदर्शन परीक्षणों से नहीं गुजरा है। (और यह है कि यह कैसे रहने वाला है। हम वेब फ्रेमवर्क बनाने के व्यवसाय में हैं, न कि वेब सर्वर, इसलिए इस सर्वर को सुधारना उत्पादन वातावरण को संभालने में सक्षम होने के लिए Django के दायरे से बाहर है।)

विकास सर्वर आवश्यकतानुसार प्रत्येक अनुरोध के लिए पायथन कोड को स्वचालित रूप से पुनः लोड करता है। आपको प्रभावी होने के लिए कोड परिवर्तन के लिए सर्वर को पुनरारंभ करने की आवश्यकता नहीं है। हालाँकि, कुछ कार्रवाइयाँ जैसे कि फ़ाइलें जोड़ना पुनरारंभ करना ट्रिगर नहीं करता है, इसलिए आपको इन मामलों में सर्वर को पुनरारंभ करना होगा।

यदि आप लिनक्स का उपयोग कर रहे हैं और pyinotify स्थापित pyinotify , तो कर्नेल सिग्नल का उपयोग सर्वर को ऑटोरेलोएड करने के लिए किया जाएगा (बजाय प्रत्येक सेकंड में फ़ाइल संशोधन टाइमस्टैम्प्स को पोलिंग करने के लिए)। यह बड़ी परियोजनाओं के लिए बेहतर स्केलिंग, कोड संशोधन के लिए प्रतिक्रिया समय में कमी, अधिक मजबूत परिवर्तन का पता लगाने और बैटरी उपयोग में कमी प्रदान करता है।

जब आप सर्वर शुरू करते हैं, और हर बार जब आप सर्वर को चलाते समय पायथन कोड बदलते हैं, तो सिस्टम चेक फ्रेमवर्क कुछ सामान्य त्रुटियों के लिए आपके पूरे Django प्रोजेक्ट की जांच करेगा ( check कमांड देखें)। यदि कोई त्रुटि पाई जाती है, तो उन्हें मानक आउटपुट पर प्रिंट किया जाएगा।

आप जितने चाहें उतने समवर्ती सर्वर चला सकते हैं, जब तक कि वे अलग-अलग बंदरगाहों पर हों। बस एक से अधिक बार django-admin runserver निष्पादित करें।

ध्यान दें कि डिफ़ॉल्ट IP पता, 127.0.0.1 , आपके नेटवर्क पर अन्य मशीनों से सुलभ नहीं है। नेटवर्क पर अन्य मशीनों के लिए अपने विकास सर्वर को देखने के लिए, अपने स्वयं के आईपी पते (जैसे 192.168.2.1 ) या 0.0.0.0 या :: (IPv6 सक्षम के साथ) का उपयोग करें।

आप कोष्ठक से घिरा एक IPv6 पता प्रदान कर सकते हैं (जैसे [200a::1]:8000 )। यह स्वचालित रूप से IPv6 समर्थन को सक्षम करेगा।

एक होस्टनाम जिसमें ASCII- केवल वर्ण हैं, का भी उपयोग किया जा सकता है।

यदि runserver ऐप को सक्षम किया गया है (नई परियोजनाओं में डिफ़ॉल्ट) तो runserver कमांड को अपने स्वयं के runserver कमांड के साथ ओवरराइड किया जाएगा।

सर्वर के प्रत्येक अनुरोध और प्रतिक्रिया की लॉगिंग django.server को भेजी जाती है।

--noreload

ऑटो-लोडर को निष्क्रिय करता है। इसका मतलब यह है कि सर्वर चलने के दौरान आपके द्वारा किया गया कोई भी पायथन कोड परिवर्तन नहीं करेगा, यदि विशेष पायथन मॉड्यूल पहले से ही मेमोरी में लोड हो चुके हैं।

--nothreading

विकास सर्वर में थ्रेडिंग का उपयोग अक्षम करता है। सर्वर को डिफ़ॉल्ट रूप से गुणा किया गया है।

--ipv6, -6

विकास सर्वर के लिए IPv6 का उपयोग करता है। यह डिफ़ॉल्ट IP पते को 127.0.0.1 से ::1 बदलता है।

विभिन्न बंदरगाहों और पते का उपयोग करने के उदाहरण

पोर्ट 8000 IP पते पर 127.0.0.1 :

django-admin runserver

पोर्ट आईपी पते पर पोर्ट 1.2.3.4 :

django-admin runserver 1.2.3.4:8000

पोर्ट 7000 IP पते पर 127.0.0.1 :

django-admin runserver 7000

पोर्ट 7000 IP पते पर 1.2.3.4 :

django-admin runserver 1.2.3.4:7000

IPv6 पते पर पोर्ट 8000 ::1 :

django-admin runserver -6

पोर्ट 7000 IPv6 पते पर ::1 :

django-admin runserver -6 7000

पोर्ट 7000 IPv6 पते पर 2001:0db8:1234:5678::9 :

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

होस्ट localhost आईपीवी 4 पते पर पोर्ट 8000:

django-admin runserver localhost:8000

होस्ट localhost IPv6 पते पर पोर्ट 8000:

django-admin runserver -6 localhost:8000

विकास सर्वर के साथ स्थिर फ़ाइलों की सेवा

डिफ़ॉल्ट रूप से, विकास सर्वर आपकी साइट के लिए किसी भी स्थिर फ़ाइलों की सेवा नहीं करता है (जैसे कि CSS फाइलें, चित्र, MEDIA_URL तहत चीजें और इसके आगे)। यदि आप स्थिर मीडिया की सेवा करने के लिए Django को कॉन्फ़िगर करना चाहते हैं, तो स्थैतिक फ़ाइलों को प्रबंधित करें (जैसे चित्र, जावास्क्रिप्ट, सीएसएस) पढ़ें।

sendtestemail

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

निर्दिष्ट निर्दिष्ट प्राप्तकर्ता को एक परीक्षण ईमेल भेजता है (Django के माध्यम से ईमेल भेजने की पुष्टि करने के लिए) काम कर रहा है। उदाहरण के लिए:

django-admin sendtestemail [email protected] [email protected]

कुछ विकल्प हैं, और आप उनमें से किसी भी संयोजन का उपयोग कर सकते हैं:

--managers

mail_managers() का उपयोग करके MANAGERS में निर्दिष्ट ईमेल पते को मेल करता है।

--admins

mail_admins() का उपयोग करके mail_admins() में निर्दिष्ट ईमेल पतों को मेल करता है।

shell

django-admin shell

पायथन इंटरएक्टिव दुभाषिया शुरू करता है।

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

उपयोग करने के लिए शेल निर्दिष्ट करता है। डिफ़ॉल्ट रूप से, Django IPython या bpython उपयोग करेगा यदि या तो स्थापित है। यदि दोनों स्थापित हैं, तो निर्दिष्ट करें कि आपको कौन सा पसंद है:

IPython:

django-admin shell -i ipython

bpython:

django-admin shell -i bpython

यदि आपके पास "रिच" शेल स्थापित है, लेकिन "प्लेन" पायथन दुभाषिया के उपयोग को बाध्य करना चाहते हैं, तो python को इंटरफ़ेस नाम के रूप में उपयोग करें, जैसे:

django-admin shell -i python
--nostartup

"सादे" पायथन दुभाषिया के लिए स्टार्टअप स्क्रिप्ट पढ़ने में अक्षम करता है। डिफ़ॉल्ट रूप से, PYTHONSTARTUP पर्यावरण चर या ~/.pythonrc.py स्क्रिप्ट द्वारा ~/.pythonrc.py स्क्रिप्ट को पढ़ा जाता है।

--command COMMAND, -c COMMAND

आप इसे Django के रूप में निष्पादित करने के लिए एक स्ट्रिंग के रूप में एक कमांड पास करते हैं, जैसे:

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

इसे निष्पादित करने के लिए आप मानक इनपुट पर कोड भी पास कर सकते हैं। उदाहरण के लिए:

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

विंडोज पर, REPL उस प्लेटफॉर्म पर select.select() की कार्यान्वयन सीमाओं के कारण आउटपुट है।

showmigrations

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

किसी प्रोजेक्ट में सभी माइग्रेशन दिखाता है। आप दो स्वरूपों में से एक का चयन कर सकते हैं:

--list, -l

उन सभी ऐप्स की सूची देता है, जो Django के बारे में जानते हैं, प्रत्येक ऐप के लिए उपलब्ध माइग्रेशन, और प्रत्येक माइग्रेशन लागू होता है या नहीं (माइग्रेशन नाम के आगे एक [X] द्वारा चिह्नित)।

बिना माइग्रेशन वाले ऐप्स भी सूचीबद्ध हैं, लेकिन उनके अंतर्गत मुद्रित (no migrations) हैं।

यह डिफ़ॉल्ट आउटपुट स्वरूप है।

--plan, -p

माइग्रेशन प्लान दिखाता है कि Django माइग्रेशन लागू करने का पालन करेगा। जैसे - सूची, लागू माइग्रेशन एक [X] द्वारा चिह्नित होते हैं। 2 और इसके बाद के संस्करण के लिए - प्रवासन की सभी निर्भरताएं भी दर्शाई जाएंगी।

app_label तर्क आउटपुट को सीमित करते हैं, हालांकि, प्रदान किए गए ऐप्स की निर्भरता भी शामिल हो सकती है।

--database DATABASE

डेटाबेस को जांच करने के लिए निर्दिष्ट करता है। डिफ़ॉल्ट default से default

sqlflush

django-admin sqlflush

SQL कथन मुद्रित करता है जिसे flush कमांड के लिए निष्पादित किया जाएगा।

--database DATABASE

SQL को प्रिंट करने के लिए डेटाबेस निर्दिष्ट करता है। डिफ़ॉल्ट default से default

sqlmigrate

django-admin sqlmigrate app_label migration_name

नामित माइग्रेशन के लिए SQL प्रिंट करता है। इसके लिए एक सक्रिय डेटाबेस कनेक्शन की आवश्यकता होती है, जिसका उपयोग वह बाधा नामों को हल करने के लिए करेगा; इसका मतलब है कि आपको उस डेटाबेस की एक कॉपी के खिलाफ SQL उत्पन्न करना चाहिए जिसे आप बाद में इसे लागू करना चाहते हैं।

ध्यान दें कि sqlmigrate अपने आउटपुट को रंगीन नहीं करता है।

--backwards

माइग्रेशन को अनपेक्षित करने के लिए SQL उत्पन्न करता है। डिफ़ॉल्ट रूप से, SQL बनाई गई फ़ॉरवर्ड दिशा में माइग्रेशन चलाने के लिए है।

--database DATABASE

SQL उत्पन्न करने के लिए डेटाबेस निर्दिष्ट करता है। डिफ़ॉल्ट default से default

sqlsequencereset

django-admin sqlsequencereset app_label [app_label ...]

दिए गए ऐप के नाम के लिए अनुक्रमों को रीसेट करने के लिए SQL स्टेटमेंट प्रिंट करता है।

अनुक्रम कुछ डेटाबेस इंजनों द्वारा उपयोग किए जाने वाले अनुक्रमित होते हैं जो स्वचालित रूप से बढ़े हुए क्षेत्रों के लिए अगली उपलब्ध संख्या को ट्रैक करने के लिए होते हैं।

एसक्यूएल उत्पन्न करने के लिए इस कमांड का उपयोग करें जो ऐसे मामलों को ठीक करेगा जहां एक अनुक्रम अपने आप बढ़े हुए फ़ील्ड डेटा के साथ सिंक से बाहर है।

--database DATABASE

SQL को प्रिंट करने के लिए डेटाबेस निर्दिष्ट करता है। डिफ़ॉल्ट default से default

squashmigrations

django-admin squashmigrations app_label [start_migration_name] migration_name

यदि संभव हो तो कम से कम माइग्रेशन में app_label लिए माइग्रेशन और माइग्रेशन_ app_label सहित migration_name को कम कर देता है। परिणामस्वरूप स्क्वाश किए गए माइग्रेशन असुरक्षित लोगों के साथ सुरक्षित रूप से रह सकते हैं। अधिक जानकारी के लिए, कृपया स्क्वाशिंग माइग्रेशन पढ़ें।

जब start_migration_name दिया जाता है, तो Django में केवल इस माइग्रेशन से शुरू होने वाले माइग्रेशन शामिल होंगे। यह RunPython और django.db.migrations.operations.RunSQL माइग्रेशन ऑपरेशंस की RunPython सीमा को कम करने में मदद करता है।

--no-optimize

स्क्वैश माइग्रेशन बनाते समय ऑप्टिमाइज़र को निष्क्रिय कर देता है। डिफ़ॉल्ट रूप से, Django परिणामी फ़ाइल के आकार को कम करने के लिए आपके माइग्रेशन के संचालन को अनुकूलित करने का प्रयास करेगा। यदि यह प्रक्रिया विफल हो रही है या गलत माइग्रेशन बना रही है, तो इस विकल्प का उपयोग करें, हालांकि कृपया व्यवहार के बारे में Django बग रिपोर्ट भी दर्ज करें, क्योंकि अनुकूलन सुरक्षित होने का मतलब है।

--noinput, --no-input

सभी उपयोगकर्ता संकेतों को दबा देता है।

--squashed-name SQUASHED_NAME
Django 2.0 में नया:

स्क्वैश माइग्रेशन का नाम सेट करता है। जब छोड़ा जाता है, तो नाम पहले और अंतिम प्रवास पर आधारित होता है, _squashed_ बीच में।

startapp

django-admin startapp name [directory]

वर्तमान निर्देशिका या दिए गए गंतव्य में दिए गए ऐप नाम के लिए एक Django ऐप निर्देशिका संरचना बनाता है।

डिफ़ॉल्ट रूप से बनाई गई निर्देशिका में एक models.py फ़ाइल और अन्य ऐप टेम्प्लेट फ़ाइलें होती हैं। ( अधिक विवरण के लिए source देखें।) यदि केवल ऐप का नाम दिया गया है, तो वर्तमान कार्यशील निर्देशिका में ऐप निर्देशिका बनाई जाएगी।

यदि वैकल्पिक गंतव्य प्रदान किया जाता है, तो Django नया बनाने के बजाय उस मौजूदा निर्देशिका का उपयोग करेगा। आप उपयोग कर सकते हैं '।' वर्तमान कार्य निर्देशिका को निरूपित करने के लिए।

उदाहरण के लिए:

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

कोई कस्टम एप्लिकेशन टेम्पलेट फ़ाइल या एक संपीड़ित फ़ाइल (करने के लिए एक पथ के साथ एक निर्देशिका के लिए पथ प्रदान करता है .tar.gz , .tar.bz2 , .tgz , .tbz , .zip एप्लिकेशन टेम्पलेट फ़ाइलों से युक्त)।

उदाहरण के लिए, यह ऐप बनाते समय दिए गए डायरेक्टरी में ऐप टेम्प्लेट की तलाश करेगा myapp :

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

Django , ऐप टेम्पलेट फ़ाइलों के साथ संग्रह को संपीड़ित करने, डाउनलोड करने और उन्हें मक्खी पर निकालने के लिए URL ( http , ) भी स्वीकार करेगा । https ftp

उदाहरण के लिए, GitHub की सुविधा का लाभ उठाते हुए रिपॉजिटरी को ज़िप फ़ाइलों के रूप में उजागर करने के लिए, आप एक URL का उपयोग कर सकते हैं:

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

निर्दिष्ट करता है कि ऐप टेम्पलेट में कौन सी फ़ाइल एक्सटेंशन टेम्पलेट इंजन के साथ प्रदान की जानी चाहिए। के लिए चूक py

--name FILES, -n FILES

निर्दिष्ट करता है कि ऐप टेम्पलेट में कौन सी फाइलें (मिलान करने वालों के अलावा --extension ) को टेम्पलेट इंजन के साथ प्रदान किया जाना चाहिए। खाली सूची में चूक।

template context मिलान करने वाले सभी फ़ाइलों के लिए प्रयोग किया जाता है:

  • startapp कमांड के लिए दिया गया कोई भी विकल्प (कमांड समर्थित विकल्पों में से)
  • app_name - कमांड के रूप में एप्लिकेशन का नाम
  • app_directory - नए बनाए गए ऐप का पूरा रास्ता
  • camel_case_app_name - ऊंट मामले प्रारूप में एप्लिकेशन का नाम
  • docs_version - प्रलेखन का संस्करण: 'dev' या '1.x'
  • django_version - Django के संस्करण, जैसे ``'2.0.3'``

चेतावनी

जब ऐप टेम्प्लेट फ़ाइलों को Django टेम्प्लेट इंजन (डिफ़ॉल्ट रूप से सभी *.py फ़ाइलों द्वारा ) के साथ प्रदान किया जाता है , तो Django निहित सभी आवारा टेम्प्लेट चर को भी बदल देगा। उदाहरण के लिए, यदि पायथन फ़ाइलों में से एक में डॉकस्ट्रिंग होता है जो टेम्पलेट रेंडरिंग से संबंधित किसी विशेष विशेषता को समझाता है, तो इसका परिणाम गलत उदाहरण हो सकता है।

इस समस्या को हल करने के लिए, आप templatetag टेम्पलेट सिंटैक्स के विभिन्न भागों को "भागने" के लिए टेम्प्लेट टैग का उपयोग कर सकते हैं ।

इसके अलावा, पायथन टेम्प्लेट फ़ाइलों की अनुमति देने के लिए जिसमें Django टेम्प्लेट लैंग्वेज सिंटैक्स होता है, साथ ही पैकेजिंग सिस्टम को बाइट-संकलित अमान्य *.py फ़ाइलों की कोशिश करने से रोकता है , के साथ समाप्त होने वाली टेम्प्लेट फ़ाइलों का .py-tpl नाम बदला जाएगा .py

startproject

django-admin startproject name [directory]

वर्तमान निर्देशिका या दिए गए गंतव्य में दिए गए प्रोजेक्ट नाम के लिए एक Django परियोजना निर्देशिका संरचना बनाता है।

डिफ़ॉल्ट रूप से, नई निर्देशिका होती है manage.py और एक प्रोजेक्ट पैकेज (जिसमें settings.py और अन्य फाइलें होती हैं)। देखें टेम्पलेट स्रोत जानकारी के लिए।

यदि केवल प्रोजेक्ट नाम दिया गया है, तो प्रोजेक्ट डायरेक्टरी और प्रोजेक्ट पैकेज दोनों का नाम दिया जाएगा <projectname> और प्रोजेक्ट डायरेक्टरी को वर्तमान वर्किंग डायरेक्टरी में बनाया जाएगा।

यदि वैकल्पिक गंतव्य प्रदान किया जाता है, तो Django उस मौजूदा निर्देशिका को प्रोजेक्ट निर्देशिका के रूप में उपयोग करेगा, और manage.py इसके भीतर प्रोजेक्ट पैकेज बनाएगा । उपयोग '।' वर्तमान कार्य निर्देशिका को निरूपित करने के लिए।

उदाहरण के लिए:

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

कोई निर्देशिका, फ़ाइल पथ या कस्टम प्रोजेक्ट टेम्पलेट का URL निर्दिष्ट करता है। startapp --template उदाहरण और उपयोग के लिए प्रलेखन देखें ।

--extension EXTENSIONS, -e EXTENSIONS

निर्दिष्ट करता है कि प्रोजेक्ट टेम्पलेट में कौन सी फ़ाइल एक्सटेंशन टेम्पलेट इंजन के साथ प्रदान की जानी चाहिए। के लिए चूक py

--name FILES, -n FILES

निर्दिष्ट करता है कि प्रोजेक्ट टेम्पलेट में (मिलान के अलावा --extension ) कौन सी फाइलें टेम्पलेट इंजन के साथ प्रदान की जानी चाहिए। खाली सूची में चूक।

template context इस्तेमाल किया जाता है:

  • startproject कमांड के लिए दिया गया कोई भी विकल्प (कमांड समर्थित विकल्पों में से)
  • project_name - कमांड में प्रोजेक्ट नाम
  • project_directory - नव निर्मित परियोजना का पूर्ण पथ
  • secret_key - SECRET_KEY सेटिंग के लिए एक यादृच्छिक कुंजी
  • docs_version - प्रलेखन का संस्करण: 'dev' या '1.x'
  • django_version - Django के संस्करण, जैसे ``'2.0.3'``

जैसा कि उल्लेख किया गया है, कृपया प्रतिपादन चेतावनी भी देखें startapp

test

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

सभी इंस्टॉल किए गए ऐप्स के लिए परीक्षण चलाता है। अधिक जानकारी के लिए Django में परीक्षण देखें ।

--failfast

परीक्षण चलाने से रोकता है और परीक्षण विफल होने के तुरंत बाद विफलता की रिपोर्ट करता है।

--testrunner TESTRUNNER

परीक्षण चलाने के लिए उपयोग किए जाने वाले परीक्षण धावक वर्ग को नियंत्रित करता है। यह मान TEST_RUNNER सेटिंग द्वारा प्रदान किए गए मान को ओवरराइड करता है ।

--noinput, --no-input

सभी उपयोगकर्ता संकेतों को दबा देता है। एक विशिष्ट संकेत एक मौजूदा परीक्षण डेटाबेस को हटाने के बारे में एक चेतावनी है।

परीक्षण धावक विकल्प

test आदेश निर्दिष्ट की ओर से विकल्प प्राप्त करता है --testrunner । ये डिफ़ॉल्ट परीक्षण धावक के विकल्प हैं DiscoverRunner :।

--keepdb, -k

परीक्षण रन के बीच परीक्षण डेटाबेस को संरक्षित करता है। इसके कारण दोनों को बनाने और नष्ट करने की क्रियाओं में फायदा होता है, जिससे परीक्षण चलाने के समय में कमी आ सकती है, विशेष रूप से एक बड़े परीक्षण सूट में। यदि परीक्षण डेटाबेस मौजूद नहीं है, तो इसे पहले रन पर बनाया जाएगा और फिर प्रत्येक बाद के रन के लिए संरक्षित किया जाएगा। परीक्षण सूट चलाने से पहले कोई भी अप्रयुक्त माइग्रेशन भी परीक्षण डेटाबेस पर लागू किया जाएगा।

--reverse, -r

विपरीत निष्पादन क्रम में मामलों का परीक्षण करता है। यह उन परीक्षणों के दुष्प्रभावों को कम करने में मदद कर सकता है जो ठीक से पृथक नहीं हैं। इस विकल्प का उपयोग करते समय परीक्षण वर्ग द्वारा समूहीकरण संरक्षित है।

--debug-mode

परीक्षण चलाने DEBUG से True पहले सेटिंग सेट करता है । यह परीक्षण विफलताओं के निवारण में मदद कर सकता है।

--debug-sql, -d

विफल परीक्षणों के लिए SQL लॉगिंग सक्षम करता है । यदि --verbosity है 2 , तो उत्तीर्ण परीक्षणों में प्रश्न भी आउटपुट हैं।

--parallel [N]

अलग-अलग समानांतर प्रक्रियाओं में परीक्षण चलाता है। चूंकि आधुनिक प्रोसेसरों में कई कोर होते हैं, इसलिए यह परीक्षणों को तेज गति से चलाने की अनुमति देता है।

डिफ़ॉल्ट रूप --parallel से प्रति कोर के हिसाब से एक प्रक्रिया चलती है multiprocessing.cpu_count() । आप या तो विकल्प का मान, उदाहरण के लिए --parallel=4 , या DJANGO_TEST_PROCESSES पर्यावरण चर सेट करके प्रक्रियाओं की संख्या को समायोजित कर सकते हैं ।

Django परीक्षण मामलों को वितरित करता है - unittest.TestCase उपवर्ग - उपप्रकारों को। यदि कॉन्फ़िगर प्रक्रियाओं की तुलना में कम परीक्षण मामले हैं, तो Django तदनुसार प्रक्रियाओं की संख्या कम कर देगा।

प्रत्येक प्रक्रिया का अपना डेटाबेस होता है। आपको यह सुनिश्चित करना होगा कि विभिन्न परीक्षण मामले समान संसाधनों तक नहीं पहुँचें। उदाहरण के लिए, उन मामलों का परीक्षण करें जो फाइल सिस्टम को स्पर्श करते हैं, उन्हें अपने स्वयं के उपयोग के लिए एक अस्थायी निर्देशिका बनाना चाहिए।

इस विकल्प को tblib सही ढंग से ट्रेसबैक प्रदर्शित करने के लिए तीसरे पक्ष के पैकेज की आवश्यकता होती है:

$ pip install tblib

यह सुविधा विंडोज पर उपलब्ध नहीं है। यह Oracle डेटाबेस बैकएंड के साथ काम नहीं करता है।

यदि आप pdb परीक्षण डीबग करते समय उपयोग करना चाहते हैं , तो आपको समानांतर निष्पादन ( --parallel=1 ) को अक्षम करना होगा । bdb.BdbQuit यदि आप ऐसा नहीं करते हैं तो आपको कुछ दिखाई देगा ।

चेतावनी

जब परीक्षण समानांतरण सक्षम होता है और परीक्षण विफल हो जाता है, तो Django अपवाद ट्रेसबैक प्रदर्शित करने में असमर्थ हो सकता है। इससे डिबगिंग मुश्किल हो सकती है। यदि आप इस समस्या का सामना करते हैं, तो विफलता के ट्रेसबैक को देखने के लिए समानांतर परीक्षण के बिना प्रभावित परीक्षण चलाएं।

यह एक ज्ञात सीमा है। यह उन प्रक्रियाओं के बीच आदान-प्रदान करने के लिए वस्तुओं को क्रमबद्ध करने की आवश्यकता से उत्पन्न होता है। देखें कि क्या अचार बनाकर खाया जा सकता है? ब्योरा हेतु।

--tag TAGS

केवल निर्दिष्ट टैग के साथ चिह्नित परीक्षण चलाता है । कई बार निर्दिष्ट किया जा सकता है और साथ जोड़ा जा सकता है test --exclude-tag

--exclude-tag EXCLUDE_TAGS

निर्दिष्ट टैग के साथ चिह्नित परीक्षणों को छोड़ देता है । कई बार निर्दिष्ट किया जा सकता है और साथ जोड़ा जा सकता है test --tag

testserver

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

एक Django विकास सर्वर (के रूप में runserver ) दिए गए स्थिरता (ओं) से डेटा का उपयोग कर चलाता है ।

उदाहरण के लिए, यह आदेश:

django-admin testserver mydata.json

… निम्न चरणों का पालन करेगा:

  1. एक परीक्षण डेटाबेस बनाएँ, में वर्णित के रूप परीक्षण डेटाबेस
  2. दिए गए जुड़नार से स्थिरता डेटा के साथ परीक्षण डेटाबेस पॉपुलेट करें। (फिक्स्चर पर अधिक जानकारी के लिए, loaddata ऊपर दिए गए दस्तावेज़ देखें ।)
  3. runserver अपने उत्पादन डेटाबेस के बजाय इस नए बनाए गए परीक्षण डेटाबेस पर इंगित Django विकास सर्वर (के रूप में ) चलाता है ।

यह कई तरीकों से उपयोगी है:

  • जब आप इकाई परीक्षण लिख रहे हैं कि आपके विचार कुछ निश्चित डेटा के साथ कैसे काम करते हैं, तो आप testserver वेब ब्राउज़र में विचारों के साथ बातचीत करने के लिए मैन्युअल रूप से उपयोग कर सकते हैं ।
  • मान लीजिए कि आप अपने Django एप्लिकेशन को विकसित कर रहे हैं और आपके पास एक ऐसे डेटाबेस की "प्रीस्टाइन" कॉपी है जिसे आप इंटर करना चाहते हैं। आप अपने डेटाबेस को एक स्थिरता ( dumpdata कमांड का उपयोग करके , ऊपर समझाया गया है) डंप कर सकते हैं , फिर testserver उस डेटा के साथ अपने वेब एप्लिकेशन को चलाने के लिए उपयोग कर सकते हैं। इस व्यवस्था के साथ, आपके पास किसी भी तरह से अपने डेटा को गड़बड़ाने का लचीलापन है, यह जानते हुए कि आप जो भी डेटा परिवर्तन कर रहे हैं वह केवल एक परीक्षण डेटाबेस के लिए किया जा रहा है।

ध्यान दें कि यह सर्वर स्वचालित रूप से आपके पायथन स्रोत कोड में परिवर्तन का पता नहीं लगाता है (जैसा कि runserver करता है)। हालांकि, यह टेम्प्लेट में परिवर्तन का पता लगाता है।

--addrport ADDRPORT

के डिफॉल्ट से एक अलग पोर्ट या आईपी एड्रेस और पोर्ट निर्दिष्ट करता है 127.0.0.1:8000 । यह मान बिल्कुल उसी प्रारूप का अनुसरण करता है और runserver कमांड के तर्क के समान कार्य करता है ।

उदाहरण:

पोर्ट 7000 पर परीक्षण सर्वर को चलाने के लिए fixture1 और fixture2 :

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

(उपर्युक्त कथन समतुल्य हैं। हम दोनों को यह प्रदर्शित करने के लिए शामिल करते हैं कि यह तय नहीं करता है कि विकल्प तर्क वितर्क से पहले या बाद में आते हैं।)

एक test स्थिरता के साथ 1.2.3.4:7000 पर चलने के लिए :

django-admin testserver --addrport 1.2.3.4:7000 test
--noinput, --no-input

सभी उपयोगकर्ता संकेतों को दबा देता है। एक विशिष्ट संकेत एक मौजूदा परीक्षण डेटाबेस को हटाने के बारे में एक चेतावनी है।

अनुप्रयोगों द्वारा प्रदान की गई कमांड

कुछ कमांड केवल तभी उपलब्ध होते हैं जब django.contrib आवेदन जो उन्हें implements करता है INSTALLED_APPS । यह खंड उन्हें उनके आवेदन द्वारा समूहीकृत का वर्णन करता है।

django.contrib.auth

changepassword

django-admin changepassword [<username>]

यह कमांड केवल तभी उपलब्ध है जब Django का प्रमाणीकरण सिस्टम ( django.contrib.auth ) स्थापित है।

उपयोगकर्ता का पासवर्ड बदलने की अनुमति देता है। यह आपको दिए गए उपयोगकर्ता के लिए दो बार एक नया पासवर्ड दर्ज करने का संकेत देता है। यदि प्रविष्टियाँ समान हैं, तो यह तुरंत नया पासवर्ड बन जाता है। यदि आप एक उपयोगकर्ता की आपूर्ति नहीं करते हैं, तो कमांड उस पासवर्ड को बदलने का प्रयास करेगा जिसका उपयोगकर्ता नाम वर्तमान उपयोगकर्ता से मेल खाता है।

--database DATABASE

उपयोगकर्ता के लिए क्वेरी के लिए डेटाबेस निर्दिष्ट करता है। के लिए चूक default

उदाहरण का उपयोग:

django-admin changepassword ringo

createsuperuser

django-admin createsuperuser

यह कमांड केवल तभी उपलब्ध है जब Django का प्रमाणीकरण सिस्टम ( django.contrib.auth ) स्थापित है।

एक सुपरयूज़र खाता (एक उपयोगकर्ता जिसके पास सभी अनुमतियां हैं) बनाता है। यह उपयोगी है यदि आपको एक प्रारंभिक सुपरयुसर खाता बनाने की आवश्यकता है या यदि आपको प्रोग्रामिक रूप से अपनी साइट (ओं) के लिए सुपरयूज़र खाते बनाने की आवश्यकता है।

अंतःक्रियात्मक रूप से चलाने पर, यह कमांड नए सुपरयुजर खाते के लिए एक पासवर्ड के लिए संकेत देगा। जब गैर-अंतःक्रियात्मक रूप से चलाया जाता है, तो कोई पासवर्ड सेट नहीं किया जाएगा, और सुपरयूजर खाता तब तक लॉग इन नहीं कर पाएगा जब तक कि इसके लिए मैन्युअल रूप से पासवर्ड सेट नहीं किया गया हो।

--username USERNAME
--email EMAIL

नए खाते के उपयोगकर्ता नाम और ईमेल पते को कमांड लाइन पर --username और --email तर्कों का उपयोग करके आपूर्ति की जा सकती है । यदि उनमें से कोई भी आपूर्ति नहीं की जाती है, createsuperuser तो अंतःक्रियात्मक रूप से चलने पर इसके लिए संकेत देगा।

--database DATABASE

उस डेटाबेस को निर्दिष्ट करता है जिसमें सुपरयूजर ऑब्जेक्ट सहेजा जाएगा।

get_input_data() यदि आप डेटा इनपुट और सत्यापन को अनुकूलित करना चाहते हैं, तो आप प्रबंधन कमांड को ओवरक्लास कर सकते हैं और ओवरराइड कर सकते हैं। मौजूदा कार्यान्वयन और विधि के मापदंडों के विवरण के लिए स्रोत कोड से परामर्श करें। उदाहरण के लिए, यह उपयोगी हो सकता है यदि आपके पास ForeignKey मौजूद है REQUIRED_FIELDS और मौजूदा उदाहरण की प्राथमिक कुंजी दर्ज करने के बजाय एक उदाहरण बनाना चाहता है।

django.contrib.contenttypes

remove_stale_contenttypes

django-admin remove_stale_contenttypes

यह कमांड केवल तभी उपलब्ध है जब Django का कंटेंटेप्स ऐप ( django.contrib.contenttypes ) इंस्टॉल हो।

आपके डेटाबेस में बासी सामग्री प्रकार (हटाए गए मॉडल से) हटाता है। कोई भी ऑब्जेक्ट जो हटाए गए सामग्री प्रकारों पर निर्भर करता है, उसे भी हटा दिया जाएगा। हटाए जाने के साथ आगे बढ़ने के लिए यह पुष्टि करने से पहले हटाए गए ऑब्जेक्ट की एक सूची प्रदर्शित की जाएगी।

--database DATABASE

डेटाबेस का उपयोग करने के लिए निर्दिष्ट करता है। के लिए चूक default

django.contrib.gis

ogrinspect

यह कमांड केवल तभी उपलब्ध है जब GeoDjango ( django.contrib.gis ) स्थापित हो।

कृपया description GeoDjango प्रलेखन में इसका संदर्भ लें ।

django.contrib.sessions

clearsessions

django-admin clearsessions

समाप्त सत्र समाप्त करने के लिए क्रोन जॉब या सीधे सफाई के रूप में चलाया जा सकता है।

django.contrib.sitemaps

ping_google

यदि यह आदेश ही उपलब्ध है साइटमैप ढांचे ( django.contrib.sitemaps ) स्थापित किया गया है।

कृपया description साइटमैप दस्तावेज़ में इसका संदर्भ लें ।

django.contrib.staticfiles

collectstatic

यह कमांड केवल तभी उपलब्ध है जब स्टैटिक फाइल्स एप्लिकेशन ( django.contrib.staticfiles ) स्थापित हो।

अपने को देखें description में staticfiles प्रलेखन।

findstatic

यह कमांड केवल तभी उपलब्ध है जब स्टैटिक फाइल्स एप्लिकेशन ( django.contrib.staticfiles ) स्थापित हो।

अपने को देखें description में staticfiles प्रलेखन।

डिफ़ॉल्ट विकल्प

यद्यपि कुछ कमांड अपने स्वयं के कस्टम विकल्प की अनुमति दे सकते हैं, प्रत्येक कमांड निम्नलिखित विकल्पों के लिए अनुमति देता है:

--pythonpath PYTHONPATH

दिए गए फ़ाइल सिस्टम पथ को पायथन आयात खोज पथ में जोड़ता है । यदि यह प्रदान नहीं किया गया है, django-admin तो PYTHONPATH पर्यावरण चर का उपयोग करेगा ।

यह विकल्प अनावश्यक है manage.py , क्योंकि यह आपके लिए पाइथन पथ को स्थापित करने का ध्यान रखता है।

उदाहरण का उपयोग:

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

उपयोग करने के लिए सेटिंग्स मॉड्यूल को निर्दिष्ट करता है। सेटिंग्स मॉड्यूल पायथन पैकेज सिंटैक्स में होना चाहिए, जैसे mysite.settings । यदि यह प्रदान नहीं किया गया है, django-admin तो DJANGO_SETTINGS_MODULE पर्यावरण चर का उपयोग करेगा ।

यह विकल्प अनावश्यक है manage.py , क्योंकि यह settings.py वर्तमान परियोजना से डिफ़ॉल्ट रूप से उपयोग होता है।

उदाहरण का उपयोग:

django-admin migrate --settings=mysite.settings
--traceback

जब CommandError उठाया जाता है तो एक पूर्ण स्टैक ट्रेस प्रदर्शित करता है। डिफ़ॉल्ट रूप से, django-admin एक साधारण त्रुटि संदेश तब दिखाई देगा जब कोई CommandError और अपवाद के लिए एक पूर्ण स्टैक ट्रेस होता है।

उदाहरण का उपयोग:

django-admin migrate --traceback
--verbosity {0,1,2,3}, -v {0,1,2,3}

अधिसूचना और डिबग जानकारी की मात्रा निर्दिष्ट करता है जो एक कमांड को कंसोल पर प्रिंट करना चाहिए।

  • 0 मतलब कोई आउटपुट नहीं।
  • 1 सामान्य उत्पादन (डिफ़ॉल्ट) का मतलब है।
  • 2 वर्बोज़ आउटपुट का मतलब है।
  • 3 बहुत वर्बोज़ आउटपुट का मतलब है ।

उदाहरण का उपयोग:

django-admin migrate --verbosity 2
--no-color

रंगीन कमांड आउटपुट को निष्क्रिय करता है। कुछ कमांड अपने आउटपुट को रंगीन बनाने के लिए प्रारूपित करते हैं। उदाहरण के लिए, त्रुटियों को लाल रंग में कंसोल पर प्रिंट किया जाएगा और एसक्यूएल स्टेटमेंट को सिंटैक्स हाइलाइट किया जाएगा।

उदाहरण का उपयोग:

django-admin runserver --no-color

अतिरिक्त निकेत

सिंटेक्स रंग

django-admin / manage.py अपने टर्मिनल एएनएसआई रंग उत्पादन का समर्थन करता है, तो आज्ञाओं सुंदर रंग कोडित उत्पादन का उपयोग करेगा। यदि आप किसी अन्य प्रोग्राम में कमांड के आउटपुट को पाइप कर रहे हैं तो यह कलर कोड का उपयोग नहीं करेगा।

विंडोज के तहत, देशी कंसोल एएनएसआई से बचने के क्रम का समर्थन नहीं करता है, इसलिए डिफ़ॉल्ट रूप से कोई रंग आउटपुट नहीं है। लेकिन आप ANSICON थर्ड-पार्टी टूल इंस्टॉल कर सकते हैं , Django कमांड्स इसकी मौजूदगी का पता लगाएगा और यूनिक्स-आधारित प्लेटफॉर्मों की तरह ही इसकी आउटपुट का इस्तेमाल कलर आउटपुट के लिए करेगा।

सिंटैक्स हाइलाइटिंग के लिए इस्तेमाल किए गए रंगों को अनुकूलित किया जा सकता है। तीन रंग पट्टियों के साथ Django के जहाज:

  • dark , टर्मिनलों के लिए जो एक काले रंग की पृष्ठभूमि पर सफेद पाठ दिखाते हैं। यह डिफ़ॉल्ट पैलेट है।
  • light , टर्मिनलों के लिए उपयुक्त है जो एक सफेद पृष्ठभूमि पर काला पाठ दिखाते हैं।
  • nocolor , जो वाक्य रचना हाइलाइटिंग को निष्क्रिय करता है।

आप DJANGO_COLORS जिस पैलेट का उपयोग करना चाहते हैं, उसे निर्दिष्ट करने के लिए एक पर्यावरण चर सेट करके एक पैलेट का चयन करें। उदाहरण के लिए, light यूनिक्स या OS / X BASH शेल के तहत पैलेट को निर्दिष्ट करने के लिए , आप कमांड प्रॉम्प्ट पर निम्नलिखित को चलाएंगे:

export DJANGO_COLORS="light"

आप उन रंगों को भी अनुकूलित कर सकते हैं जो उपयोग किए जाते हैं। Django कई भूमिकाओं को निर्दिष्ट करता है जिसमें रंग का उपयोग किया जाता है:

  • error - एक बड़ी त्रुटि।
  • notice - एक छोटी सी त्रुटि।
  • success - सफलता।
  • warning - चेतावनी।
  • sql_field - SQL में एक मॉडल फ़ील्ड का नाम।
  • sql_coltype - SQL में एक मॉडल फील्ड का प्रकार।
  • sql_keyword - एक एसक्यूएल कीवर्ड।
  • sql_table - SQL में एक मॉडल का नाम।
  • http_info - 1XX HTTP सूचनात्मक सर्वर प्रतिक्रिया।
  • http_success - एक 2XX HTTP सफलता सर्वर प्रतिक्रिया।
  • http_not_modified - एक 304 HTTP नहीं संशोधित सर्वर प्रतिक्रिया।
  • http_redirect - 304 के अलावा एक 3XX HTTP रीडायरेक्ट सर्वर प्रतिक्रिया।
  • http_not_found - एक 404 HTTP नहीं मिला सर्वर प्रतिक्रिया।
  • http_bad_request - 404 के अलावा 4XX HTTP बैड रिक्वेस्ट सर्वर रिस्पॉन्स।
  • http_server_error - 5XX HTTP सर्वर त्रुटि प्रतिक्रिया।
  • migrate_heading - माइग्रेशन मैनेजमेंट कमांड में हेडिंग।
  • migrate_label - एक माइग्रेशन नाम।

इनमें से प्रत्येक भूमिका को निम्नलिखित सूची से एक विशिष्ट अग्रभूमि और पृष्ठभूमि रंग सौंपा जा सकता है:

  • black
  • red
  • green
  • yellow
  • blue
  • magenta
  • cyan
  • white

इनमें से प्रत्येक रंग को निम्नलिखित प्रदर्शन विकल्पों का उपयोग करके संशोधित किया जा सकता है:

  • bold
  • underscore
  • blink
  • reverse
  • conceal

एक रंग विनिर्देश निम्नलिखित पैटर्न में से एक है:

  • role=fg
  • role=fg/bg
  • role=fg,option,option
  • role=fg/bg,option,option

जहां role एक वैध रंग भूमिका का नाम fg है, अग्रभूमि रंग bg है, पृष्ठभूमि रंग है और प्रत्येक option रंग को संशोधित करने वाले विकल्पों में से एक है। एकाधिक रंग विनिर्देशों को अर्धविराम द्वारा अलग किया जाता है। उदाहरण के लिए:

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

यह निर्दिष्ट करेगा कि त्रुटियों को नीले पर पीले रंग का उपयोग करके प्रदर्शित किया जाएगा, और मैजेंटा का उपयोग करके प्रदर्शित किए गए नोटिस। अन्य सभी रंग भूमिकाओं को अनसुना छोड़ दिया जाएगा।

बेस पैलेट का विस्तार करके रंगों को भी निर्दिष्ट किया जा सकता है। यदि आप किसी रंग विनिर्देश में एक पैलेट नाम डालते हैं, तो उस पैलेट द्वारा निहित सभी रंगों को लोड किया जाएगा। इसलिए:

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

त्रुटियों और सूचनाओं के लिए रंगों को छोड़कर , हल्के रंग पैलेट में सभी रंगों के उपयोग को निर्दिष्ट किया जाएगा जो कि निर्दिष्ट के रूप में ओवरराइड किया जाएगा।

बैश पूरा होना

यदि आप बैश शेल का उपयोग करते हैं, तो Django बैश पूर्ण स्क्रिप्ट को स्थापित करने पर विचार करें, जो extras/django_bash_completion Django स्रोत वितरण में रहता है । यह उदाहरण के लिए, टैब को पूरा करने django-admin और manage.py आदेशों को सक्षम करता है ...

  • टाइप करें django-admin
  • सभी उपलब्ध विकल्पों को देखने के लिए [TAB] दबाएँ।
  • टाइप करें sql , फिर [TAB], सभी उपलब्ध विकल्पों को देखने के लिए जिनके नाम से शुरू होता है sql

कस्टमाइज़ किए गए कार्यों को जोड़ने के लिए implements देखें ।

आपके कोड से रनिंग मैनेजमेंट कमांड

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

कोड उपयोग से प्रबंधन कमांड को कॉल करने के लिए call_command

name
कॉल या कमांड ऑब्जेक्ट को कमांड का नाम। जब तक ऑब्जेक्ट को परीक्षण के लिए आवश्यक न हो, तब तक नाम देना पसंद किया जाता है।
*args
कमांड द्वारा स्वीकार किए गए तर्कों की एक सूची। तर्क पार्सर को तर्क दिए जाते हैं, इसलिए आप उसी शैली का उपयोग कर सकते हैं जैसे आप कमांड लाइन पर करेंगे। उदाहरण के लिए, call_command('flush', '--verbosity=0')
**options
कमांड लाइन पर नामित विकल्प। विकल्प को तर्क पार्सर को ट्रिगर किए बिना कमांड को पास किया जाता है, जिसका अर्थ है कि आपको सही प्रकार पास करने की आवश्यकता होगी। उदाहरण के लिए, call_command('flush', verbosity=0) (शून्य को एक स्ट्रिंग के बजाय पूर्णांक होना चाहिए)।

उदाहरण:

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

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

ध्यान दें कि कोई भी तर्क न रखने वाले कमांड विकल्प कीवर्ड के साथ पास किए जाते हैं True या False , जैसा कि आप interactive ऊपर दिए गए विकल्प से देख सकते हैं ।

नामांकित तर्क निम्नलिखित सिंटैक्स में से किसी एक का उपयोग करके पारित किया जा सकता है:

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

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

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

कुछ कमांड विकल्प अलग-अलग नामों का उपयोग करते समय है call_command() बजाय django-admin या manage.py । उदाहरण के लिए, django-admin createsuperuser --no-input अनुवाद करता है call_command('createsuperuser', interactive=False) । यह जानने के लिए कि किस कीवर्ड तर्क नाम का उपयोग करना है call_command() , dest पास किए गए तर्क के लिए कमांड के सोर्स कोड की जांच करें parser.add_argument()

कमांड विकल्प जो कई विकल्प लेते हैं उन्हें एक सूची दी जाती है:

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

के रिटर्न मान call_command() समारोह की वापसी मान के समान है handle() आदेश की विधि।

आउटपुट पुनर्निर्देशन

ध्यान दें कि आप मानक आउटपुट और त्रुटि धाराओं को पुनर्निर्देशित कर सकते हैं क्योंकि सभी कमांड विकल्प stdout और stderr विकल्प का समर्थन करते हैं। उदाहरण के लिए, आप लिख सकते हैं:

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

Original text