Django 2.1 - Writing your first Django app, part 2

अपना पहला Django ऐप, भाग 2 लिखना




django

अपना पहला Django ऐप, भाग 2 लिखना

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

डेटाबेस सेटअप

अब, mysite/settings.py खोलें। यह एक सामान्य पायथन मॉड्यूल है जिसमें Django सेटिंग्स का प्रतिनिधित्व करने वाले मॉड्यूल-स्तरीय चर हैं।

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

यदि आप किसी अन्य डेटाबेस का उपयोग करना चाहते हैं, तो उचित डेटाबेस बाइंडिंग स्थापित करें और अपने डेटाबेस कनेक्शन सेटिंग्स से मेल करने के लिए DATABASES 'default' आइटम में निम्नलिखित कुंजियों को बदलें:

  • ENGINE - या तो 'django.db.backends.sqlite3' , 'django.db.backends.postgresql' , 'django.db.backends.mysql' , या 'django.db.backends.oracle' । अन्य बैकएंड भी उपलब्ध हैं
  • NAME - आपके डेटाबेस का नाम। यदि आप SQLite का उपयोग कर रहे हैं, तो डेटाबेस आपके कंप्यूटर पर एक फ़ाइल होगी; उस स्थिति में, NAME फ़ाइल का फ़ाइल नाम सहित पूर्ण निरपेक्ष पथ होना चाहिए। डिफ़ॉल्ट मान, os.path.join(BASE_DIR, 'db.sqlite3') , आपकी परियोजना निर्देशिका में फ़ाइल संग्रहीत करेगा।

यदि आप अपने डेटाबेस के रूप में SQLite का उपयोग नहीं कर रहे हैं, तो USER , PASSWORD , और HOST जैसी अतिरिक्त सेटिंग्स जोड़ी जानी चाहिए। अधिक जानकारी के लिए, DATABASES लिए संदर्भ प्रलेखन देखें।

SQLite के अलावा अन्य डेटाबेस के लिए

यदि आप SQLite के अलावा किसी डेटाबेस का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आपने इस बिंदु से एक डेटाबेस बनाया है। " CREATE DATABASE database_name; " के साथ ऐसा CREATE DATABASE database_name; “आपके डेटाबेस के इंटरेक्टिव प्रॉम्प्ट के भीतर।

यह भी सुनिश्चित करें कि mysite/settings.py में प्रदान किए गए डेटाबेस उपयोगकर्ता के पास "डेटाबेस बनाएं" विशेषाधिकार हैं। यह एक परीक्षण डेटाबेस की स्वचालित निर्माण की अनुमति देता है जिसकी बाद के ट्यूटोरियल में आवश्यकता होगी।

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

जब आप mysite/settings.py संपादित कर रहे हों, तो TIME_ZONE को अपने समय क्षेत्र में सेट करें।

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

डिफ़ॉल्ट रूप से, INSTALLED_APPS में निम्नलिखित ऐप्स होते हैं, जो सभी Django के साथ आते हैं:

ये एप्लिकेशन आम मामले के लिए एक सुविधा के रूप में डिफ़ॉल्ट रूप से शामिल हैं।

इनमें से कुछ एप्लिकेशन कम से कम एक डेटाबेस तालिका का उपयोग करते हैं, हालांकि, इसलिए हमें डेटाबेस में तालिकाओं को बनाने से पहले हमें उनका उपयोग करने की आवश्यकता है। ऐसा करने के लिए, निम्नलिखित कमांड चलाएँ:

$ python manage.py migrate
...\> py manage.py migrate

migrate कमांड INSTALLED_APPS सेटिंग को देखता है और आपकी mysite/settings.py फ़ाइल में डेटाबेस सेटिंग्स के अनुसार कोई आवश्यक डेटाबेस टेबल बनाता है और डेटाबेस माइग्रेशन ऐप के साथ भेज दिया जाता है (हम बाद में उन्हें कवर करेंगे)। आपको लागू होने वाले प्रत्येक माइग्रेशन के लिए एक संदेश दिखाई देगा। यदि आप रुचि रखते हैं, तो अपने डेटाबेस के लिए कमांड-लाइन क्लाइंट चलाएं और \dt (PostgreSQL), SHOW TABLES; टाइप करें SHOW TABLES; (MySQL), .schema (SQLite), या SELECT TABLE_NAME FROM USER_TABLES; (ओरेकल) Django बनाया तालिका प्रदर्शित करने के लिए।

न्यूनतम के लिए

जैसा कि हमने ऊपर कहा, सामान्य मामले के लिए डिफ़ॉल्ट एप्लिकेशन शामिल हैं, लेकिन हर किसी को उनकी आवश्यकता नहीं है। यदि आपको उनमें से किसी या सभी की आवश्यकता नहीं है, तो migrate से पहले INSTALLED_APPS से उपयुक्त लाइन (टिप्पणी) को बेझिझक टिप्पणी करें या हटाएं। migrate कमांड केवल INSTALLED_APPS में ऐप्स के लिए माइग्रेशन चलाएगा।

मॉडल बनाना

अब हम आपके मॉडल को परिभाषित करेंगे - अनिवार्य रूप से, आपका डेटाबेस लेआउट, अतिरिक्त मेटाडेटा के साथ।

दर्शन

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

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

हमारे साधारण मतदान ऐप में, हम दो मॉडल बनाएंगे: Question और Choice । एक Question में एक प्रश्न और एक प्रकाशन तिथि है। एक Choice में दो क्षेत्र होते हैं: Choice का पाठ और एक वोट टैली। प्रत्येक Choice एक Question साथ जुड़ा हुआ है।

इन अवधारणाओं को सरल पायथन वर्गों द्वारा दर्शाया गया है। polls/models.py फ़ाइल को संपादित करें ताकि ऐसा लगे:

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

कोड सीधा है। प्रत्येक मॉडल को एक वर्ग द्वारा दर्शाया जाता है जो django.db.models.Model । प्रत्येक मॉडल में कई वर्ग चर होते हैं, जिनमें से प्रत्येक मॉडल में एक डेटाबेस फ़ील्ड का प्रतिनिधित्व करता है।

प्रत्येक फ़ील्ड को Field श्रेणी के उदाहरण द्वारा दर्शाया जाता है - उदाहरण के लिए, वर्ण फ़ील्ड के लिए CharField और CharField लिए DateTimeField । यह Django बताता है कि प्रत्येक क्षेत्र किस प्रकार का डेटा रखता है।

प्रत्येक Field उदाहरण (जैसे question_text या pub_date ) का नाम फ़ील्ड का नाम मशीन-अनुकूल प्रारूप में है। आप अपने पायथन कोड में इस मान का उपयोग करेंगे, और आपका डेटाबेस इसे कॉलम नाम के रूप में उपयोग करेगा।

आप किसी मानव-पठनीय नाम को नामित करने के लिए Field वैकल्पिक प्रथम स्थिति संबंधी तर्क का उपयोग कर सकते हैं। इसका उपयोग Django के कुछ हिस्सों में किया जाता है, और यह प्रलेखन के रूप में दोगुना हो जाता है। यदि यह फ़ील्ड प्रदान नहीं की जाती है, तो Django मशीन-पठनीय नाम का उपयोग करेगा। इस उदाहरण में, हमने केवल Question.pub_date लिए एक मानव-पठनीय नाम परिभाषित किया है। इस मॉडल के अन्य सभी क्षेत्रों के लिए, क्षेत्र का मशीन-पठनीय नाम इसके मानव-पठनीय नाम के रूप में पर्याप्त होगा।

कुछ Field वर्गों के लिए आवश्यक तर्क हैं। उदाहरण के लिए, CharField के लिए आवश्यक है कि आप इसे एक max_length । इसका उपयोग न केवल डेटाबेस स्कीमा में किया जाता है, बल्कि सत्यापन में, जैसा कि हम जल्द ही देखेंगे।

एक Field में विभिन्न वैकल्पिक तर्क भी हो सकते हैं; इस स्थिति में, हमने votes का default मान 0 पर सेट किया है।

अंत में, ध्यान दें कि एक संबंध परिभाषित किया गया है, ForeignKey का उपयोग करके। यह बताता है कि Django प्रत्येक Choice एक एकल Question से संबंधित है। Django सभी सामान्य डेटाबेस संबंधों का समर्थन करता है: कई-से-एक, कई-से-कई, और एक-से-एक।

सक्रिय मॉडल

मॉडल कोड का वह छोटा सा हिस्सा Django को बहुत सारी जानकारी देता है। इसके साथ, Django के लिए सक्षम है:

  • इस ऐप के लिए एक डेटाबेस स्कीमा (क्रिएट CREATE TABLE स्टेटमेंट) बनाएं।
  • Question और Choice वस्तुओं तक पहुंचने के लिए एक पायथन डेटाबेस-एक्सेस एपीआई बनाएं।

लेकिन सबसे पहले हमें अपने प्रोजेक्ट को बताना होगा कि polls ऐप इंस्टॉल हो गया है।

दर्शन

Django एप्लिकेशन "प्लगेबल" हैं: आप कई परियोजनाओं में एक ऐप का उपयोग कर सकते हैं, और आप ऐप्स वितरित कर सकते हैं, क्योंकि उन्हें किसी दिए गए Django इंस्टॉलेशन से बंधा नहीं होना चाहिए।

एप्लिकेशन को हमारी परियोजना में शामिल करने के लिए, हमें INSTALLED_APPS सेटिंग में इसके कॉन्फ़िगरेशन वर्ग का संदर्भ जोड़ना होगा। PollsConfig क्लास polls/apps.py फ़ाइल में है, इसलिए इसका बिंदीदार मार्ग 'polls.apps.PollsConfig'mysite/settings.py फ़ाइल को संपादित करें और उस डॉटेड पथ को INSTALLED_APPS सेटिंग में जोड़ें। यह इस तरह दिखेगा:

INSTALLED_APPS = [
    'polls.apps.PollsConfig',
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

अब Django को polls ऐप शामिल करना पता है। चलो एक और कमांड चलाते हैं:

$ python manage.py makemigrations polls
...\> py manage.py makemigrations polls

आपको निम्नलिखित के समान कुछ देखना चाहिए:

Migrations for 'polls':
  polls/migrations/0001_initial.py:
    - Create model Choice
    - Create model Question
    - Add field question to choice

makemigrations , आप Django को बता रहे हैं कि आपने अपने मॉडल में कुछ बदलाव किए हैं (इस मामले में, आपने नए बनाए हैं) और आप बदलावों को माइग्रेशन के रूप में संग्रहीत करना चाहेंगे।

माइग्रेशन यह है कि कैसे Django स्टोर आपके मॉडल (और इस तरह आपके डेटाबेस स्कीमा) में परिवर्तन करता है - वे डिस्क पर सिर्फ फाइलें हैं। आप चाहें तो अपने नए मॉडल के लिए माइग्रेशन पढ़ सकते हैं; यह फ़ाइल polls/migrations/0001_initial.py । चिंता न करें, आपको उम्मीद नहीं है कि हर बार जब Django एक बनाता है, तो आप उन्हें पढ़ सकते हैं, लेकिन वे मानव-संपादन योग्य होने के लिए डिज़ाइन किए गए हैं, यदि आप मैन्युअल रूप से यह जानना चाहते हैं कि Django चीजों को कैसे बदलता है।

एक आदेश है जो आपके लिए माइग्रेशन चलाएगा और आपके डेटाबेस स्कीमा को स्वचालित रूप से प्रबंधित करेगा - जिसे migrate कहा जाता है, और हम एक क्षण में आ जाएंगे - लेकिन पहले, आइए देखें कि एसक्यूएल कि माइग्रेशन क्या चलेगा। sqlmigrate कमांड माइग्रेशन नाम लेता है और उनकी SQL लौटाता है:

$ python manage.py sqlmigrate polls 0001
...\> py manage.py sqlmigrate polls 0001

आपको निम्नलिखित के समान कुछ देखना चाहिए (हमने पठनीयता के लिए इसे पुन: स्वरूपित किया है):

BEGIN;
--
-- Create model Choice
--
CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "choice_text" varchar(200) NOT NULL,
    "votes" integer NOT NULL
);
--
-- Create model Question
--
CREATE TABLE "polls_question" (
    "id" serial NOT NULL PRIMARY KEY,
    "question_text" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
--
-- Add field question to choice
--
ALTER TABLE "polls_choice" ADD COLUMN "question_id" integer NOT NULL;
ALTER TABLE "polls_choice" ALTER COLUMN "question_id" DROP DEFAULT;
CREATE INDEX "polls_choice_7aa0f6ee" ON "polls_choice" ("question_id");
ALTER TABLE "polls_choice"
  ADD CONSTRAINT "polls_choice_question_id_246c99a640fbbd72_fk_polls_question_id"
    FOREIGN KEY ("question_id")
    REFERENCES "polls_question" ("id")
    DEFERRABLE INITIALLY DEFERRED;

COMMIT;

निम्नलिखित पर ध्यान दें:

  • आपके द्वारा उपयोग किए जा रहे डेटाबेस के आधार पर सटीक आउटपुट अलग-अलग होगा। ऊपर दिया गया उदाहरण PostgreSQL के लिए बनाया गया है।
  • एप्लिकेशन ( polls ) और मॉडल के निचले नाम - question और choice संयोजन से तालिका के नाम स्वचालित रूप से उत्पन्न होते हैं। (आप इस व्यवहार को ओवरराइड कर सकते हैं।)
  • प्राथमिक कुंजी (आईडी) स्वचालित रूप से जुड़ जाती हैं। (आप इसे ओवरराइड भी कर सकते हैं।)
  • सम्मेलन द्वारा, Django विदेशी कुंजी फ़ील्ड नाम के लिए "_id" जोड़ता है। (हां, आप इसे ओवरराइड कर सकते हैं, साथ ही)
  • विदेशी कुंजी संबंध एक स्पष्ट FOREIGN KEY बाधा द्वारा स्पष्ट किया जाता है। DEFERRABLE भागों के बारे में चिंता मत करो; यह सिर्फ PostgreSQL को लेन-देन के अंत तक विदेशी कुंजी लागू नहीं करने के लिए कह रहा है।
  • यह आपके द्वारा उपयोग किए जा रहे डेटाबेस के अनुरूप है, इसलिए डेटाबेस-विशिष्ट फ़ील्ड प्रकार जैसे कि auto_increment (MySQL), serial (PostgreSQL), या integer primary key autoincrement (SQLite) आपके लिए स्वचालित रूप से नियंत्रित किया जाता है। समान क्षेत्र के नामों के उद्धरण के लिए जाता है - जैसे, दोहरे उद्धरण या एकल उद्धरण का उपयोग करना।
  • sqlmigrate कमांड वास्तव में आपके डेटाबेस पर माइग्रेशन नहीं चलाती है - यह सिर्फ इसे स्क्रीन पर प्रिंट करता है ताकि आप देख सकें कि SQL Django क्या सोचता है। यह जांचने के लिए उपयोगी है कि Django क्या करने जा रहा है या यदि आपके पास डेटाबेस व्यवस्थापक हैं जिन्हें परिवर्तनों के लिए SQL स्क्रिप्ट की आवश्यकता है।

यदि आप रुचि रखते हैं, तो आप python manage.py check भी चला सकते हैं; यह आपकी परियोजना में किसी भी समस्या के लिए माइग्रेशन किए बिना या डेटाबेस को छूए चेक करता है।

अब, अपने डेटाबेस में उन मॉडल तालिकाओं को बनाने के लिए फिर से migrate करें:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Rendering model states... DONE
  Applying polls.0001_initial... OK
...\> py manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Rendering model states... DONE
  Applying polls.0001_initial... OK

migrate कमांड उन सभी माइग्रेशन को लेती है जो लागू नहीं किए गए हैं (Django ट्रैक जो आपके डेटाबेस में एक विशेष तालिका का उपयोग करके लागू किए जाते हैं जिन्हें django_migrations कहा जाता है) और उन्हें आपके डेटाबेस के विरुद्ध चलाता है - अनिवार्य रूप से, स्कीमा के साथ आपके द्वारा किए गए परिवर्तनों को सिंक्रनाइज़ करना। डेटाबेस में।

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

  • अपने मॉडल बदलें ( models.py )।
  • उन परिवर्तनों के लिए माइग्रेशन बनाने के लिए python manage.py makemigrations चलाएँ
  • डेटाबेस में उन परिवर्तनों को लागू migrate लिए migrate चलाएं।

माइग्रेशन बनाने और लागू करने के लिए अलग-अलग कमांड होने का कारण यह है कि आप अपने संस्करण नियंत्रण प्रणाली के लिए माइग्रेशन करेंगे और उन्हें अपने ऐप के साथ शिप करेंगे; वे न केवल आपके विकास को आसान बनाते हैं, वे अन्य डेवलपर्स और उत्पादन में भी उपयोग करने योग्य होते हैं।

पूरी जानकारी के लिए django-admin दस्तावेज़ीकरण पढ़ें, जो कि manage.py करें manage.py उपयोगिता क्या कर सकती है।

एपीआई के साथ खेल रहा है

अब, चलो इंटरैक्टिव पायथन शेल में आशा करते हैं और निशुल्क एपीआई Django के साथ खेलते हैं। पायथन शेल को लागू करने के लिए, इस कमांड का उपयोग करें:

$ python manage.py shell
...\> py manage.py shell

हम इसका उपयोग केवल "अजगर" टाइप करने के बजाय कर रहे हैं, क्योंकि manage.py DJANGO_SETTINGS_MODULE पर्यावरण चर को सेट करता है, जो Django के पायथन आयात मार्ग को आपके mysite/settings.py फ़ाइल में देता है।

एक बार शेल में जाने के बाद, डेटाबेस एपीआई का पता लगाएं:

>>> from polls.models import Choice, Question  # Import the model classes we just wrote.

# No questions are in the system yet.
>>> Question.objects.all()
<QuerySet []>

# Create a new Question.
# Support for time zones is enabled in the default settings file, so
# Django expects a datetime with tzinfo for pub_date. Use timezone.now()
# instead of datetime.datetime.now() and it will do the right thing.
>>> from django.utils import timezone
>>> q = Question(question_text="What's new?", pub_date=timezone.now())

# Save the object into the database. You have to call save() explicitly.
>>> q.save()

# Now it has an ID.
>>> q.id
1

# Access model field values via Python attributes.
>>> q.question_text
"What's new?"
>>> q.pub_date
datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)

# Change values by changing the attributes, then calling save().
>>> q.question_text = "What's up?"
>>> q.save()

# objects.all() displays all the questions in the database.
>>> Question.objects.all()
<QuerySet [<Question: Question object (1)>]>

एक मिनट रुकिए। <Question: Question object (1)> इस वस्तु का सहायक प्रतिनिधित्व नहीं है। चलो ठीक करें कि Question मॉडल ( polls/models.py मॉडल- __str__() फ़ाइल में) को संपादित करके और Question और Choice दोनों में __str__() विधि को जोड़कर:

from django.db import models

class Question(models.Model):
    # ...
    def __str__(self):
        return self.question_text

class Choice(models.Model):
    # ...
    def __str__(self):
        return self.choice_text

अपने मॉडलों के लिए __str__() विधियों को जोड़ना महत्वपूर्ण है, न केवल इंटरेक्टिव प्रॉम्प्ट से निपटने के दौरान, बल्कि अपनी स्वयं की सुविधा के लिए, लेकिन यह भी क्योंकि ऑब्जेक्ट्स का प्रतिनिधित्व पूरे Django के स्वचालित रूप से जेनरेट किए गए व्यवस्थापक में उपयोग किया जाता है।

ध्यान दें ये सामान्य पायथन तरीके हैं। चलो एक कस्टम विधि जोड़ते हैं, सिर्फ प्रदर्शन के लिए:

import datetime

from django.db import models
from django.utils import timezone


class Question(models.Model):
    # ...
    def was_published_recently(self):
        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)

from django.utils import timezone पायथन के मानक from django.utils import timezone मॉड्यूल और Django के समय-क्षेत्र से संबंधित उपयोगिताओं को django.utils.timezone में संदर्भित करने के लिए, from django.utils import timezone और from django.utils import timezone के अलावा पर ध्यान दें। यदि आप पायथन में समय क्षेत्र के संचालन से परिचित नहीं हैं, तो आप समय क्षेत्र समर्थन डॉक्स में अधिक जान सकते हैं।

इन परिवर्तनों को सहेजें और फिर से python manage.py shell चलाकर एक नया पायथन इंटरेक्टिव शेल शुरू करें:

>>> from polls.models import Choice, Question

# Make sure our __str__() addition worked.
>>> Question.objects.all()
<QuerySet [<Question: What's up?>]>

# Django provides a rich database lookup API that's entirely driven by
# keyword arguments.
>>> Question.objects.filter(id=1)
<QuerySet [<Question: What's up?>]>
>>> Question.objects.filter(question_text__startswith='What')
<QuerySet [<Question: What's up?>]>

# Get the question that was published this year.
>>> from django.utils import timezone
>>> current_year = timezone.now().year
>>> Question.objects.get(pub_date__year=current_year)
<Question: What's up?>

# Request an ID that doesn't exist, this will raise an exception.
>>> Question.objects.get(id=2)
Traceback (most recent call last):
    ...
DoesNotExist: Question matching query does not exist.

# Lookup by a primary key is the most common case, so Django provides a
# shortcut for primary-key exact lookups.
# The following is identical to Question.objects.get(id=1).
>>> Question.objects.get(pk=1)
<Question: What's up?>

# Make sure our custom method worked.
>>> q = Question.objects.get(pk=1)
>>> q.was_published_recently()
True

# Give the Question a couple of Choices. The create call constructs a new
# Choice object, does the INSERT statement, adds the choice to the set
# of available choices and returns the new Choice object. Django creates
# a set to hold the "other side" of a ForeignKey relation
# (e.g. a question's choice) which can be accessed via the API.
>>> q = Question.objects.get(pk=1)

# Display any choices from the related object set -- none so far.
>>> q.choice_set.all()
<QuerySet []>

# Create three choices.
>>> q.choice_set.create(choice_text='Not much', votes=0)
<Choice: Not much>
>>> q.choice_set.create(choice_text='The sky', votes=0)
<Choice: The sky>
>>> c = q.choice_set.create(choice_text='Just hacking again', votes=0)

# Choice objects have API access to their related Question objects.
>>> c.question
<Question: What's up?>

# And vice versa: Question objects get access to Choice objects.
>>> q.choice_set.all()
<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>
>>> q.choice_set.count()
3

# The API automatically follows relationships as far as you need.
# Use double underscores to separate relationships.
# This works as many levels deep as you want; there's no limit.
# Find all Choices for any question whose pub_date is in this year
# (reusing the 'current_year' variable we created above).
>>> Choice.objects.filter(question__pub_date__year=current_year)
<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>

# Let's delete one of the choices. Use delete() for that.
>>> c = q.choice_set.filter(choice_text__startswith='Just hacking')
>>> c.delete()

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

प्रस्तुत है Django एडमिन

दर्शन

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

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

साइट आगंतुकों द्वारा उपयोग किए जाने का इरादा नहीं है। यह साइट प्रबंधकों के लिए है।

एक व्यवस्थापक उपयोगकर्ता बनाना

पहले हमें एक उपयोगकर्ता बनाने की आवश्यकता होगी जो व्यवस्थापक साइट पर लॉगिन कर सकता है। निम्न आदेश चलाएँ:

$ python manage.py createsuperuser
...\> py manage.py createsuperuser

अपना इच्छित उपयोगकर्ता नाम दर्ज करें और Enter दबाएँ।

Username: admin

फिर आपको अपने इच्छित ईमेल पते के लिए संकेत दिया जाएगा:

Email address: [email protected]

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

Password: **********
Password (again): *********
Superuser created successfully.

विकास सर्वर प्रारंभ करें

Django व्यवस्थापक साइट डिफ़ॉल्ट रूप से सक्रिय है। चलो विकास सर्वर शुरू करते हैं और इसे एक्सप्लोर करते हैं।

यदि सर्वर नहीं चल रहा है तो इसे शुरू करें:

$ python manage.py runserver
...\> py manage.py runserver

अब, एक वेब ब्राउज़र खोलें और अपने स्थानीय डोमेन पर "/ व्यवस्थापक /" पर जाएँ - जैसे, http://127.0.0.1:8000/admin/ । आपको व्यवस्थापक की लॉगिन स्क्रीन देखनी चाहिए:

Django व्यवस्थापक लॉगिन स्क्रीन

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

व्यवस्थापक साइट दर्ज करें

अब, पिछले चरण में आपके द्वारा बनाए गए सुपरयूज़र खाते से लॉग इन करने का प्रयास करें। आपको Django एडमिन इंडेक्स पेज देखना चाहिए:

Django व्यवस्थापक सूचकांक पृष्ठ

आपको कुछ प्रकार की संपादन योग्य सामग्री देखनी चाहिए: समूह और उपयोगकर्ता। वे django.contrib.auth द्वारा प्रदान की जाती हैं, जो Django द्वारा प्रमाणित प्रमाणीकरण ढांचा है।

पोल ऐप को एडमिन में मोडिफाई करें

लेकिन हमारा पोल ऐप कहां है? यह एडमिन इंडेक्स पेज पर प्रदर्शित नहीं होता है।

बस एक काम करना है: हमें व्यवस्थापक को यह बताने की आवश्यकता है कि Question ऑब्जेक्ट में एक व्यवस्थापक इंटरफ़ेस है। ऐसा करने के लिए, polls/admin.py फ़ाइल खोलें और इसे इस तरह से देखने के लिए संपादित करें:

from django.contrib import admin

from .models import Question

admin.site.register(Question)

मुक्त व्यवस्थापक कार्यक्षमता का अन्वेषण करें

अब जब हमने Question दर्ज कर लिया है, तो Django को पता है कि इसे व्यवस्थापक सूचकांक पृष्ठ पर प्रदर्शित किया जाना चाहिए:

Django व्यवस्थापक सूचकांक पृष्ठ, अब प्रदर्शित होने वाले चुनावों के साथ

"प्रश्न" पर क्लिक करें। अब आप प्रश्नों के लिए "परिवर्तन सूची" पृष्ठ पर हैं। यह पृष्ठ डेटाबेस के सभी प्रश्नों को प्रदर्शित करता है और आपको इसे बदलने के लिए किसी एक को चुनने देता है। "पहले क्या है?" प्रश्न हमने पहले बनाया था:

पोल सूची पृष्ठ को बदलते हैं

इसे संपादित करने के लिए "क्या चल रहा है?" सवाल पर क्लिक करें:

प्रश्न वस्तु के लिए संपादन प्रपत्र

यहाँ ध्यान देने योग्य बातें:

  • फॉर्म स्वचालित रूप से Question मॉडल से उत्पन्न होता है।
  • विभिन्न मॉडल फ़ील्ड प्रकार ( DateTimeField , CharField ) उपयुक्त HTML इनपुट विजेट के अनुरूप हैं। प्रत्येक प्रकार का क्षेत्र जानता है कि कैसे Django व्यवस्थापक में खुद को प्रदर्शित करना है।
  • प्रत्येक DateTimeField मुफ्त जावास्क्रिप्ट शॉर्टकट मिलते हैं। तिथियों को "आज" शॉर्टकट और कैलेंडर पॉपअप मिलता है, और समय को "अब" शॉर्टकट और एक सुविधाजनक पॉपअप मिलता है जो आमतौर पर दर्ज किए गए समय को सूचीबद्ध करता है।

पृष्ठ का निचला हिस्सा आपको कुछ विकल्प देता है:

  • सहेजें - इस प्रकार की वस्तु के लिए परिवर्तन-सूची पृष्ठ पर परिवर्तन और रिटर्न बचाता है।
  • संपादन सहेजें और जारी रखें - परिवर्तन सहेजता है और इस ऑब्जेक्ट के लिए व्यवस्थापक पृष्ठ को फिर से लोड करता है।
  • सहेजें और दूसरे को जोड़ें - इस प्रकार की वस्तु के लिए एक नया, रिक्त रूप सहेजता है और बदलता है।
  • हटाएं - एक नष्ट पुष्टि पृष्ठ प्रदर्शित करता है।

यदि "दिनांक प्रकाशित" का मान उस समय से मेल नहीं खाता है जब आपने ट्यूटोरियल 1 में प्रश्न बनाया है, तो इसका मतलब है कि आप TIME_ZONE सेटिंग के लिए सही मान सेट करना भूल गए हैं। इसे बदलें, पृष्ठ को फिर से लोड करें और जांचें कि सही मान प्रकट होता है।

"आज" और "अब" शॉर्टकट पर क्लिक करके "प्रकाशित तिथि" बदलें। फिर "सहेजें और संपादन जारी रखें" पर क्लिक करें। फिर ऊपरी दाईं ओर "इतिहास" पर क्लिक करें। आप Django व्यवस्थापक के माध्यम से इस ऑब्जेक्ट में किए गए सभी परिवर्तनों को सूचीबद्ध करने वाला एक पेज देखेंगे, जिसमें परिवर्तन करने वाले व्यक्ति का टाइमस्टैम्प और उपयोगकर्ता नाम है:

प्रश्न वस्तु के लिए इतिहास पृष्ठ

जब आप मॉडल API के साथ सहज होते हैं और अपने आप को व्यवस्थापक साइट के साथ परिचित करते हैं, तो इस बारे में जानने के लिए इस ट्यूटोरियल के भाग 3 को पढ़ें कि हमारे चुनाव ऐप में अधिक विचार कैसे जोड़े जाएं।