Django माइग्रेशन:एक प्राइमर

अभी देखें इस ट्यूटोरियल में रियल पायथन टीम द्वारा बनाया गया एक संबंधित वीडियो कोर्स है। अपनी समझ को गहरा करने के लिए इसे लिखित ट्यूटोरियल के साथ देखें:Django Migrations 101

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

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

भाग 1:Django माइग्रेशन:एक प्राइमर (वर्तमान लेख)
भाग 2:माइग्रेशन की गहराई में जाना
भाग 3:डेटा स्थानांतरण
वीडियो:Django 1.7 माइग्रेशन - प्राइमर

इस लेख में, आप Django माइग्रेशन के साथ सहज महसूस करेंगे और निम्नलिखित सीखेंगे:

बिना कोई SQL लिखे डेटाबेस टेबल कैसे बनाएं
अपने मॉडल बदलने के बाद अपने डेटाबेस को स्वचालित रूप से कैसे संशोधित करें
अपने डेटाबेस में किए गए परिवर्तनों को कैसे वापस लाएं

निःशुल्क बोनस: एक मुफ्त Django लर्निंग रिसोर्स गाइड (पीडीएफ) तक पहुंच प्राप्त करने के लिए यहां क्लिक करें जो आपको टिप्स और ट्रिक्स के साथ-साथ पायथन + Django वेब एप्लिकेशन बनाते समय बचने के लिए सामान्य नुकसान दिखाता है।

प्रवासन द्वारा हल की जाने वाली समस्याएं

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

सबसे पहले, यह सुनिश्चित करने के लिए कि हर कोई एक ही पृष्ठ पर है, कुछ शब्दों को शीघ्रता से परिभाषित करें। Django को एक रिलेशनल डेटाबेस के साथ काम करने के लिए डिज़ाइन किया गया है, जो एक रिलेशनल डेटाबेस मैनेजमेंट सिस्टम जैसे PostgreSQL, MySQL, या SQLite में संग्रहीत है।

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

Django द्वारा समर्थित सभी डेटाबेस सिस्टम एक रिलेशनल डेटाबेस में डेटा बनाने, पढ़ने, अपडेट करने और हटाने के लिए SQL भाषा का उपयोग करते हैं। SQL का उपयोग डेटाबेस तालिकाओं को स्वयं बनाने, बदलने और हटाने के लिए भी किया जाता है।

SQL के साथ सीधे काम करना काफी बोझिल हो सकता है, इसलिए आपके जीवन को आसान बनाने के लिए, Django एक ऑब्जेक्ट-रिलेशनल मैपर, या संक्षेप में ORM के साथ आता है। ORM ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की दुनिया में रिलेशनल डेटाबेस को मैप करता है। SQL में डेटाबेस टेबल को परिभाषित करने के बजाय, आप Python में Django मॉडल लिखते हैं। आपके मॉडल डेटाबेस फ़ील्ड को परिभाषित करते हैं, जो उनकी डेटाबेस तालिका में कॉलम के अनुरूप होते हैं।

यहां एक उदाहरण दिया गया है कि कैसे एक Django मॉडल वर्ग को डेटाबेस तालिका में मैप किया जाता है:

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

यहां कुछ तरीके दिए गए हैं जिनसे Django माइग्रेशन आपके जीवन को आसान बनाता है।

एसक्यूएल के बिना डेटाबेस परिवर्तन करना

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

Django में, माइग्रेशन मुख्य रूप से पायथन में लिखे जाते हैं, इसलिए आपको किसी भी SQL को जानने की ज़रूरत नहीं है जब तक कि आपके पास वास्तव में उन्नत उपयोग के मामले न हों।

दोहराव से बचना

एक मॉडल बनाना और फिर उसके लिए डेटाबेस टेबल बनाने के लिए SQL लिखना दोहराना होगा।

माइग्रेशन आपके मॉडल से उत्पन्न होते हैं, यह सुनिश्चित करते हुए कि आप स्वयं को दोहराना नहीं चाहते हैं।

मॉडल परिभाषाएं और डेटाबेस स्कीमा को सिंक में सुनिश्चित करना

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

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

Django माइग्रेशन के साथ, आप आसानी से कई डेटाबेस को अपने मॉडल के साथ सिंक में रख सकते हैं।

डेटाबेस स्कीमा परिवर्तन को संस्करण नियंत्रण में ट्रैक करना

एक संस्करण नियंत्रण प्रणाली, जैसे Git कोड के लिए उत्कृष्ट है, लेकिन डेटाबेस स्कीमा के लिए इतना अधिक नहीं है।

जैसा कि Django में माइग्रेशन सादा पायथन है, आप उन्हें किसी भी अन्य कोड की तरह ही एक संस्करण नियंत्रण प्रणाली में डाल सकते हैं।

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

Django प्रोजेक्ट सेट अप करना

इस पूरे ट्यूटोरियल में, आप एक उदाहरण प्रोजेक्ट के रूप में एक साधारण बिटकॉइन ट्रैकर ऐप पर काम करने जा रहे हैं।

पहला कदम Django स्थापित करना है। यहां बताया गया है कि आप वर्चुअल वातावरण का उपयोग करके Linux या macOS X पर ऐसा कैसे करते हैं:

$ python3 -m venv env
$ source env/bin/activate
(env) $ pip install "Django==2.1.*"
...
Successfully installed Django-2.1.3

अब आपने एक नया आभासी वातावरण बनाया है और उसे सक्रिय किया है, साथ ही उस आभासी वातावरण में Django स्थापित किया है।

ध्यान दें कि विंडोज़ पर, आप env/bin/activate.bat चलाएंगे source env/bin/activate . के बजाय अपने आभासी वातावरण को सक्रिय करने के लिए।

आसान पठनीयता के लिए, कंसोल उदाहरणों में (env) . शामिल नहीं होगा अब से प्रॉम्प्ट का हिस्सा।

Django स्थापित होने के साथ, आप निम्न आदेशों का उपयोग करके प्रोजेक्ट बना सकते हैं:

$ django-admin.py startproject bitcoin_tracker
$ cd bitcoin_tracker
$ python manage.py startapp historical_data

यह आपको एक आसान प्रोजेक्ट और historical_data . नामक ऐप देता है . अब आपके पास यह निर्देशिका संरचना होनी चाहिए:

bitcoin_tracker/
|
├── bitcoin_tracker/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
|
├── historical_data/
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── migrations/
│   │   └── __init__.py
|   |
│   ├── models.py
│   ├── tests.py
│   └── views.py
|
└── manage.py

bitcoin_tracker . के भीतर निर्देशिका, दो उप-निर्देशिकाएँ हैं:bitcoin_tracker प्रोजेक्ट-व्यापी फ़ाइलों और historical_data . के लिए आपके द्वारा बनाए गए ऐप के लिए फ़ाइलें हैं।

अब, एक मॉडल बनाने के लिए, इस वर्ग को historical_data/models.py . में जोड़ें :

class PriceHistory(models.Model):
    date = models.DateTimeField(auto_now_add=True)
    price = models.DecimalField(max_digits=7, decimal_places=2)
    volume = models.PositiveIntegerField()

बिटकॉइन की कीमतों पर नज़र रखने के लिए यह मूल मॉडल है।

साथ ही, नए बनाए गए ऐप को settings.INSTALLED_APPS में जोड़ना न भूलें। . bitcoin_tracker/settings.pyखोलें और historical_data संलग्न करें सूची में INSTALLED_APPS , इस तरह:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'historical_data',
]

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

माइग्रेशन बनाना

बनाए गए मॉडल के साथ, आपको सबसे पहले इसके लिए एक माइग्रेशन बनाना होगा। आप इसे निम्न आदेश के साथ कर सकते हैं:

$ python manage.py makemigrations historical_data
Migrations for 'historical_data':
  historical_data/migrations/0001_initial.py
    - Create model PriceHistory

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

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

bitcoin_tracker/
|
├── bitcoin_tracker/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
|
├── historical_data/
│   ├── migrations/
│   │   ├── 0001_initial.py
│   │   └── __init__.py
|   |
│   ├── __init__.py
│   ├── admin.py
│   ├── apps.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
|
├── db.sqlite3
└── manage.py

जैसा कि आप देख सकते हैं, migrations निर्देशिका में अब एक नई फ़ाइल है:0001_initial.py ।

नोट: आप देख सकते हैं कि makemigrations चल रहा है कमांड ने फाइल भी बनाई db.sqlite3 , जिसमें आपका SQLite डेटाबेस शामिल है।

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

यह व्यवहार SQLite3 के लिए अद्वितीय है। यदि आप PostgreSQL या MySQL जैसे किसी अन्य डेटाबेस बैकएंड का उपयोग करते हैं, तो आपको पहले डेटाबेस स्वयं बनाना होगा चल रहा है makemigrations ।

आप dbshell . के साथ डेटाबेस पर एक नज़र डाल सकते हैं प्रबंधन आदेश। SQLite में, सभी तालिकाओं को सूचीबद्ध करने का आदेश केवल .tables . है :

$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .tables
sqlite>

डेटाबेस अभी भी खाली है। जब आप माइग्रेशन लागू करेंगे तो यह बदल जाएगा। टाइप करें .quit SQLite शेल से बाहर निकलने के लिए।

माइग्रेशन लागू करना

आपने अब माइग्रेशन बना लिया है, लेकिन वास्तव में डेटाबेस में कोई भी बदलाव करने के लिए, आपको इसे प्रबंधन कमांड migrate के साथ लागू करना होगा। :

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying historical_data.0001_initial... OK
  Applying sessions.0001_initial... OK

यहाँ बहुत कुछ हो रहा है! आउटपुट के अनुसार, आपका माइग्रेशन सफलतापूर्वक लागू कर दिया गया है। लेकिन अन्य सभी पलायन कहाँ से आते हैं?

सेटिंग याद रखें INSTALLED_APPS ? वहां सूचीबद्ध कुछ अन्य ऐप्स भी माइग्रेशन के साथ आते हैं, और migrate प्रबंधन आदेश डिफ़ॉल्ट रूप से सभी इंस्टॉल किए गए ऐप्स के लिए माइग्रेशन लागू करता है।

डेटाबेस पर एक और नज़र डालें:

$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .tables
auth_group                    django_admin_log
auth_group_permissions        django_content_type
auth_permission               django_migrations
auth_user                     django_session
auth_user_groups              historical_data_pricehistory
auth_user_user_permissions
sqlite>

अब कई टेबल हैं। उनके नाम से आपको उनके उद्देश्य का अंदाजा हो जाता है। पिछले चरण में आपके द्वारा जनरेट किए गए माइग्रेशन ने historical_data_pricehistory बनाया है टेबल। आइए .schema . का उपयोग करके इसका निरीक्षण करें आदेश:

sqlite> .schema --indent historical_data_pricehistory
CREATE TABLE IF NOT EXISTS "historical_data_pricehistory"(
  "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "date" datetime NOT NULL,
  "price" decimal NOT NULL,
  "volume" integer unsigned NOT NULL
);

.schema कमांड CREATE . को प्रिंट करता है वह कथन जिसे आप तालिका बनाने के लिए निष्पादित करेंगे। पैरामीटर --indent इसे अच्छी तरह से प्रारूपित करता है। भले ही आप SQL सिंटैक्स से परिचित न हों, आप देख सकते हैं कि historical_data_pricehistory का स्कीमा तालिका PriceHistory . के क्षेत्रों को दर्शाती है मॉडल।

प्रत्येक फ़ील्ड के लिए एक कॉलम है और एक अतिरिक्त कॉलम id . है प्राथमिक कुंजी के लिए, जिसे Django स्वचालित रूप से तब तक बनाता है जब तक कि आप स्पष्ट रूप से अपने मॉडल में प्राथमिक कुंजी निर्दिष्ट नहीं करते।

यदि आप migrate चलाते हैं तो यहां क्या होता है फिर से आदेश दें:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
  No migrations to apply.

कुछ नहीं! Django को याद है कि कौन से माइग्रेशन पहले ही लागू हो चुके हैं और उन्हें फिर से चलाने का प्रयास नहीं करता है।

यह ध्यान देने योग्य है कि आप migrate . को भी सीमित कर सकते हैं एक ही ऐप के लिए प्रबंधन आदेश:

$ python manage.py migrate historical_data
Operations to perform:
 Apply all migrations: historical_data
Running migrations:
 No migrations to apply.

जैसा कि आप देख सकते हैं, Django अब केवल historical_data . के लिए माइग्रेशन लागू करता है ऐप।

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

मॉडल बदलना

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

जब आप किसी मॉडल की परिभाषा बदलते हैं, तो इन मॉडलों को संग्रहीत करने के लिए उपयोग की जाने वाली डेटाबेस तालिकाएँ भी बदलनी पड़ती हैं। यदि आपकी मॉडल परिभाषाएं आपके वर्तमान डेटाबेस स्कीमा से मेल नहीं खाती हैं, तो आप संभवतः एक django.db.utils.OperationalError में चलेंगे। ।

तो आप डेटाबेस टेबल कैसे बदलते हैं? माइग्रेशन बनाकर और लागू करके।

अपने बिटकॉइन ट्रैकर का परीक्षण करते समय, आपको पता चलता है कि आपने गलती की है। लोग बिटकॉइन के अंश बेच रहे हैं, इसलिए फ़ील्ड volume DecimalField . प्रकार का होना चाहिए इसके बजाय PositiveIntegerField ।

आइए इस तरह दिखने के लिए मॉडल बदलें:

class PriceHistory(models.Model):
    date = models.DateTimeField(auto_now_add=True)
    price = models.DecimalField(max_digits=7, decimal_places=2)
    volume = models.DecimalField(max_digits=7, decimal_places=3)

माइग्रेशन के बिना, आपको PositiveIntegerField को चालू करने के लिए SQL सिंटैक्स का पता लगाना होगा एक DecimalField . में . सौभाग्य से, Django आपके लिए इसे संभाल लेगा। बस इसे माइग्रेशन करने के लिए कहें:

$ python manage.py makemigrations
Migrations for 'historical_data':
  historical_data/migrations/0002_auto_20181112_1950.py
    - Alter field volume on pricehistory

नोट: माइग्रेशन फ़ाइल का नाम (0002_auto_20181112_1950.py ) वर्तमान समय पर आधारित है और यदि आप अपने सिस्टम का अनुसरण करते हैं तो यह भिन्न होगा।

अब आप इस माइग्रेशन को अपने डेटाबेस में लागू करें:

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, historical_data, sessions
Running migrations:
  Applying historical_data.0002_auto_20181112_1950... OK

माइग्रेशन सफलतापूर्वक लागू कर दिया गया है, इसलिए आप dbshell . का उपयोग कर सकते हैं यह सत्यापित करने के लिए कि परिवर्तनों का प्रभाव था:

$ python manage.py dbshell
SQLite version 3.19.3 2017-06-27 16:48:08
Enter ".help" for usage hints.
sqlite> .schema --indent historical_data_pricehistory
CREATE TABLE IF NOT EXISTS "historical_data_pricehistory" (
  "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "date" datetime NOT NULL,
  "price" decimal NOT NULL,
  "volume" decimal NOT NULL
);

यदि आप नए स्कीमा की तुलना उस स्कीमा से करते हैं जिसे आपने पहले देखा था, तो आप देखेंगे कि volume का प्रकार कॉलम integer . से बदल गया है से decimal volume . के परिवर्तन को प्रतिबिंबित करने के लिए PositiveIntegerField . से मॉडल में फ़ील्ड से DecimalField ।

माइग्रेशन को सूचीबद्ध करना

यदि आप जानना चाहते हैं कि Django प्रोजेक्ट में कौन से माइग्रेशन मौजूद हैं, तो आपको migrations को खोदने की ज़रूरत नहीं है आपके इंस्टॉल किए गए ऐप्स की निर्देशिका। आप showmigrations का उपयोग कर सकते हैं आदेश:

$ ./manage.py showmigrations
admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
 [X] 0003_logentry_add_action_flag_choices
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [X] 0009_alter_user_last_name_max_length
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
historical_data
 [X] 0001_initial
 [X] 0002_auto_20181112_1950
sessions
 [X] 0001_initial

यह प्रोजेक्ट के सभी ऐप्स और प्रत्येक ऐप से जुड़े माइग्रेशन को सूचीबद्ध करता है। साथ ही, यह एक बड़ा X लगाएगा पहले से लागू किए जा चुके माइग्रेशन के बगल में।

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

माइग्रेशन लागू नहीं करना

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

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

सौभाग्य से, पलायन को एकतरफा रास्ता नहीं होना चाहिए। कई मामलों में, माइग्रेशन को लागू न करके माइग्रेशन के प्रभावों को पूर्ववत किया जा सकता है। माइग्रेशन को लागू न करने के लिए, आपको migrate . पर कॉल करना होगा ऐप के नाम और माइग्रेशन के नाम के साथ पहले वह माइग्रेशन जिसे आप लागू नहीं करना चाहते हैं।

अगर आप माइग्रेशन को वापस लाना चाहते हैं 0002_auto_20181112_1950 आपके historical_data . में ऐप, आपको पास करना होगा 0001_initial migrate . के तर्क के रूप में आदेश:

$ python manage.py migrate historical_data 0001_initial
Operations to perform:
  Target specific migration: 0001_initial, from historical_data
Running migrations:
  Rendering model states... DONE
  Unapplying historical_data.0002_auto_20181112_1950... OK

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

किसी माइग्रेशन को लागू न करने से उसकी माइग्रेशन फ़ाइल नहीं हटती. अगली बार जब आप migrate आदेश, माइग्रेशन फिर से लागू किया जाएगा।

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

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

उस माइग्रेशन को लागू करने से कॉलम फिर से बन जाएगा, लेकिन यह उस कॉलम में संग्रहीत डेटा को वापस नहीं लाएगा!

जब आप माइग्रेशन नामों के साथ काम कर रहे होते हैं, तो Django आपको माइग्रेशन के पूरे नाम को बताने के लिए मजबूर न करके आपको कुछ कीस्ट्रोक्स बचाता है। इसे विशिष्ट रूप से पहचानने के लिए बस नाम की पर्याप्त आवश्यकता है।

पिछले उदाहरण में, python manage.py migrate historical_data 0001 चलाने के लिए पर्याप्त होता ।

नामांतरण का नामकरण

उपरोक्त उदाहरण में, Django टाइमस्टैम्प के आधार पर माइग्रेशन के लिए एक नाम लेकर आया है—कुछ इस तरह *0002_auto_20181112_1950 . यदि आप इससे खुश नहीं हैं, तो आप --name . का उपयोग कर सकते हैं कस्टम नाम प्रदान करने के लिए पैरामीटर (.py . के बिना एक्सटेंशन)।

इसे आज़माने के लिए, आपको सबसे पहले पुराने माइग्रेशन को हटाना होगा। आपने इसे पहले ही लागू नहीं किया है, ताकि आप फ़ाइल को सुरक्षित रूप से हटा सकें:

$ rm historical_data/migrations/0002_auto_20181112_1950.py

अब आप इसे और अधिक वर्णनात्मक नाम के साथ फिर से बना सकते हैं:

$ ./manage.py makemigrations historical_data --name switch_to_decimals

यह 0002_switch_to_decimals के नए नाम को छोड़कर पहले जैसा ही माइग्रेशन बनाएगा ।

निष्कर्ष

आपने इस ट्यूटोरियल में काफी कुछ सीखा है और Django माइग्रेशन के मूल सिद्धांतों को सीखा है।

संक्षेप में, Django माइग्रेशन का उपयोग करने के लिए बुनियादी कदम इस तरह दिखते हैं:

मॉडल बनाएं या अपडेट करें
चलाएं ./manage.py makemigrations <app_name>
चलाएं ./manage.py migrate सब कुछ माइग्रेट करने के लिए या ./manage.py migrate <app_name> किसी एक ऐप को माइग्रेट करने के लिए
आवश्यकतानुसार दोहराएं

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

यदि आपने पहले अपने डेटाबेस तालिकाओं को हस्तलिखित SQL के साथ बनाया और संशोधित किया है, तो अब आप इस कार्य को Django माइग्रेशन को सौंप कर अधिक कुशल हो गए हैं।

इस श्रृंखला के अगले ट्यूटोरियल में, आप इस विषय में गहराई से जानेंगे और सीखेंगे कि कैसे Django माइग्रेशन हुड के तहत काम करता है।

चीयर्स!