Django प्रवासन में गहरी खुदाई

यह हमारी Django माइग्रेशन श्रृंखला का दूसरा लेख है:

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

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

इस लेख के अंत तक, आपको पता चल जाएगा:

• कैसे Django माइग्रेशन का ट्रैक रखता है
• माइग्रेशन कैसे जानते हैं कि कौन-सा डेटाबेस संचालन करना है
• माइग्रेशन के बीच निर्भरता को कैसे परिभाषित किया जाता है

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

यह लेख bitcoin_tracker . का उपयोग करता है Django प्रवासन में निर्मित Django परियोजना:एक प्राइमर। आप उस लेख के माध्यम से काम करके उस प्रोजेक्ट को फिर से बना सकते हैं या आप स्रोत कोड डाउनलोड कर सकते हैं:

स्रोत कोड डाउनलोड करें: इस लेख में आप जिस Django माइग्रेशन प्रोजेक्ट का उपयोग करेंगे उसका कोड डाउनलोड करने के लिए यहां क्लिक करें।

Django कैसे जानता है कि कौन सा माइग्रेशन लागू करना है

आइए श्रृंखला के पिछले लेख के अंतिम चरण को फिर से देखें। आपने एक माइग्रेशन बनाया और फिर python manage.py migrate . के साथ सभी उपलब्ध माइग्रेशन लागू किए .यदि वह आदेश सफलतापूर्वक चला, तो आपकी डेटाबेस तालिका अब आपके मॉडल की परिभाषाओं से मेल खाती है।

यदि आप उस आदेश को फिर से चलाते हैं तो क्या होगा? आइए इसे आजमाएं:

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

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

Django एक डेटाबेस तालिका का उपयोग करता है जिसे django_migrations . कहा जाता है . पहली बार जब आप कोई माइग्रेशन लागू करते हैं तो Django स्वचालित रूप से आपके डेटाबेस में यह तालिका बनाता है। लागू या नकली प्रत्येक माइग्रेशन के लिए, तालिका में एक नई पंक्ति डाली जाती है।

उदाहरण के लिए, हमारे bitcoin_tracker . में यह तालिका कैसी दिखती है परियोजना:

जैसा कि आप देख सकते हैं, प्रत्येक लागू माइग्रेशन के लिए एक प्रविष्टि है। तालिका में न केवल हमारे historical_data . से माइग्रेशन शामिल हैं ऐप, लेकिन अन्य सभी इंस्टॉल किए गए ऐप्स से माइग्रेशन भी।

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

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

माइग्रेशन फ़ाइल

क्या होता है जब आप python manage.py makemigrations <appname> run चलाते हैं ? Django आपके ऐप में मॉडलों में किए गए बदलावों को ढूंढता है <appname> . यदि इसे जोड़े गए मॉडल की तरह कोई मिलता है, तो यह migrations में एक माइग्रेशन फ़ाइल बनाता है उपनिर्देशिका। इस माइग्रेशन फ़ाइल में आपके डेटाबेस स्कीमा को आपकी मॉडल परिभाषा के साथ सिंक में लाने के लिए संचालन की एक सूची है।

नोट: आपका ऐप INSTALLED_APPS . में सूचीबद्ध होना चाहिए सेटिंग, और इसमें एक migrations होना चाहिए एक __init__.py . के साथ निर्देशिका फ़ाइल। अन्यथा Django इसके लिए कोई माइग्रेशन नहीं बनाएगा।

migrations जब आप startapp . के साथ एक नया ऐप बनाते हैं तो डायरेक्टरी अपने आप बन जाती है प्रबंधन आदेश, लेकिन मैन्युअल रूप से ऐप बनाते समय भूलना आसान है।

माइग्रेशन फ़ाइलें केवल पायथन हैं, तो आइए historical_prices में पहली माइग्रेशन फ़ाइल पर एक नज़र डालते हैं अनुप्रयोग। आप इसे historical_prices/migrations/0001_initial.py पर देख सकते हैं . यह कुछ इस तरह दिखना चाहिए:

from django.db import models, migrations

class Migration(migrations.Migration):
    dependencies = []
    operations = [
        migrations.CreateModel(
            name='PriceHistory',
            fields=[
                ('id', models.AutoField(
                    verbose_name='ID',
                    serialize=False,
                    primary_key=True,
                    auto_created=True)),
                ('date', models.DateTimeField(auto_now_add=True)),
                ('price', models.DecimalField(decimal_places=2, max_digits=5)),
                ('volume', models.PositiveIntegerField()),
                ('total_btc', models.PositiveIntegerField()),
            ],
            options={
            },
            bases=(models.Model,),
        ),
    ]

जैसा कि आप देख सकते हैं, इसमें एक एकल वर्ग है जिसे migrations . कहा जाता है जो django.db.migrations.Migration . से इनहेरिट करता है . जब आप इसे माइग्रेशन लागू करने के लिए कहेंगे तो यह वह वर्ग है जिसे माइग्रेशन फ्रेमवर्क ढूंढेगा और निष्पादित करेगा।

migrations कक्षा में दो मुख्य सूचियाँ हैं:

1. dependencies
2. operations

माइग्रेशन ऑपरेशन

आइए देखें operations पहले सूची। इस तालिका में वे ऑपरेशन हैं जो माइग्रेशन के हिस्से के रूप में किए जाने हैं। ऑपरेशन django.db.migrations.operations.base.Operation वर्ग के उपवर्ग हैं। . यहाँ सामान्य ऑपरेशन हैं जो Django में बनाए गए हैं:

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

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

नोट: कुछ मामलों में, हो सकता है कि Django आपके परिवर्तनों का सही ढंग से पता न लगा पाए। यदि आप किसी मॉडल का नाम बदलते हैं और उसके कई क्षेत्रों को बदलते हैं, तो Django इसे एक नए मॉडल के लिए गलती कर सकता है।

RenameModel . के बजाय और कई AlterField संचालन, यह एक DeleteModel create बनाएगा और एक CreateModel कार्यवाही। मॉडल के लिए डेटाबेस तालिका का नाम बदलने के बजाय, यह इसे छोड़ देगा और नए नाम के साथ एक नई तालिका बनाएगा, प्रभावी रूप से आपके सभी डेटा को हटा देगा!

उत्पादन डेटा पर चलाने से पहले जेनरेट किए गए माइग्रेशन की जांच करने और अपने डेटाबेस की एक प्रति पर उनका परीक्षण करने की आदत बनाएं।

Django उन्नत उपयोग के मामलों के लिए तीन और ऑपरेशन कक्षाएं प्रदान करता है:

1. RunSQL आपको डेटाबेस में कस्टम SQL चलाने की अनुमति देता है।
2. RunPython आपको कोई भी पायथन कोड चलाने की अनुमति देता है।
3. SeparateDatabaseAndState उन्नत उपयोगों के लिए एक विशेष ऑपरेशन है।

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

Django 2.0 के बाद से, django.contrib.postgres.operations में कुछ PostgreSQL-विशिष्ट संचालन भी उपलब्ध हैं। जिसका उपयोग आप विभिन्न PostgreSQL एक्सटेंशन स्थापित करने के लिए कर सकते हैं:

• BtreeGinExtension
• BtreeGistExtension
• CITextExtension
• CryptoExtension
• HStoreExtension
• TrigramExtension
• UnaccentExtension

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

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

माइग्रेशन निर्भरता

dependencies माइग्रेशन क्लास में सूची में कोई भी माइग्रेशन होता है जिसे इस माइग्रेशन को लागू करने से पहले लागू किया जाना चाहिए।

0001_initial.py . में आपने ऊपर जो माइग्रेशन देखा है, उससे पहले कुछ भी लागू नहीं करना है, इसलिए कोई निर्भरता नहीं है। आइए historical_prices . में दूसरे माइग्रेशन पर एक नजर डालते हैं अनुप्रयोग। फ़ाइल में 0002_switch_to_decimals.py , dependencies migrations . की विशेषता एक प्रविष्टि है:

from django.db import migrations, models

class Migration(migrations.Migration):
    dependencies = [
        ('historical_data', '0001_initial'),
    ]
    operations = [
        migrations.AlterField(
            model_name='pricehistory',
            name='volume',
            field=models.DecimalField(decimal_places=3, max_digits=7),
        ),
    ]

ऊपर दी गई निर्भरता कहती है कि माइग्रेशन 0001_initial ऐप का historical_data पहले चलाया जाना चाहिए। यह समझ में आता है, क्योंकि माइग्रेशन 0001_initial उस फ़ील्ड वाली तालिका बनाता है जिसमें माइग्रेशन 0002_switch_to_decimals . है बदलना चाहता है।

माइग्रेशन किसी अन्य ऐप से माइग्रेशन पर भी निर्भर हो सकता है, जैसे:

class Migration(migrations.Migration):
    ...

    dependencies = [
        ('auth', '0009_alter_user_last_name_max_length'),
    ]

यह आमतौर पर तब आवश्यक होता है जब किसी मॉडल में किसी अन्य ऐप में किसी मॉडल की ओर इशारा करने वाली विदेशी कुंजी होती है।

वैकल्पिक रूप से, आप यह भी लागू कर सकते हैं कि माइग्रेशन पहले . चलाया जाता है विशेषता का उपयोग करके एक और माइग्रेशन run_before :

class Migration(migrations.Migration):
    ...

    run_before = [
        ('third_party_app', '0001_initial'),
    ]

निर्भरता को भी जोड़ा जा सकता है ताकि आपके पास कई निर्भरताएं हो सकें। यह कार्यक्षमता बहुत अधिक लचीलापन प्रदान करती है, क्योंकि आप विदेशी कुंजियों को समायोजित कर सकते हैं जो विभिन्न ऐप्स के मॉडल पर निर्भर करती हैं।

माइग्रेशन के बीच निर्भरता को स्पष्ट रूप से परिभाषित करने के विकल्प का अर्थ यह भी है कि माइग्रेशन की संख्या (आमतौर पर 0001) , 0002 , 0003 , ...) उस क्रम का कड़ाई से प्रतिनिधित्व नहीं करता है जिसमें माइग्रेशन लागू किए जाते हैं। आप अपनी इच्छानुसार कोई भी निर्भरता जोड़ सकते हैं और इस प्रकार सभी माइग्रेशन को फिर से नंबर दिए बिना ऑर्डर को नियंत्रित कर सकते हैं।

माइग्रेशन देखना

आपको आमतौर पर उस SQL ​​​​के बारे में चिंता करने की ज़रूरत नहीं है जो माइग्रेशन उत्पन्न करता है। लेकिन अगर आप दोबारा जांचना चाहते हैं कि जेनरेट किया गया SQL समझ में आता है या बस उत्सुक हैं कि यह कैसा दिखता है, तो Django ने आपको sqlmigrate के साथ कवर किया है प्रबंधन आदेश:

$ python manage.py sqlmigrate historical_data 0001
BEGIN;
--
-- Create model PriceHistory
--
CREATE TABLE "historical_data_pricehistory" (
    "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
    "date" datetime NOT NULL,
    "price" decimal NOT NULL,
    "volume" integer unsigned NOT NULL
);
COMMIT;

ऐसा करने से आपके settings.py में डेटाबेस के आधार पर, निर्दिष्ट माइग्रेशन द्वारा जेनरेट की जाने वाली अंतर्निहित SQL क्वेरी की सूची बन जाएगी फ़ाइल। जब आप पैरामीटर पास करते हैं --backwards , Django माइग्रेशन को लागू न करने के लिए SQL जेनरेट करता है:

$ python manage.py sqlmigrate --backwards historical_data 0001
BEGIN;
--
-- Create model PriceHistory
--
DROP TABLE "historical_data_pricehistory";
COMMIT;

एक बार जब आप sqlmigrate . का आउटपुट देखते हैं थोड़े अधिक जटिल प्रवास के लिए, आप शायद इस बात की सराहना करें कि आपको यह सभी SQL हाथ से बनाने की आवश्यकता नहीं है!

कैसे Django आपके मॉडल में परिवर्तन का पता लगाता है

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

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

Django के साथ शतरंज खेलना

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

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

अगली बार बोर्ड को देखते समय, ग्रैंडमास्टर को यह याद नहीं रहता कि पिछली बार शतरंज की बिसात कैसी दिखती थी, लेकिन वह पिछली चालों के अपने नोट्स को पढ़ सकती है और शतरंज की बिसात की तरह दिखने वाले मानसिक मॉडल का निर्माण कर सकती है।

अब, जब आप चिल्लाते हैं migrate , ग्रैंडमास्टर एक अन्य शतरंज की बिसात पर सभी रिकॉर्ड की गई चालों को फिर से चलाएगा और एक स्प्रेडशीट में नोट करेगा कि उसके कौन से रिकॉर्ड पहले ही लागू हो चुके हैं। यह दूसरा शतरंज बोर्ड आपका डेटाबेस है, और स्प्रेडशीट django_migrations . है टेबल।

यह सादृश्य काफी उपयुक्त है, क्योंकि यह अच्छी तरह से Django माइग्रेशन के कुछ व्यवहारों को दिखाता है:

• Django माइग्रेशन कुशल होने का प्रयास करते हैं: जैसे ग्रैंडमास्टर मानता है कि आपने कम से कम चालें चली हैं, वैसे ही Django सबसे कुशल माइग्रेशन बनाने का प्रयास करेगा। अगर आप A . नाम की कोई फ़ील्ड जोड़ते हैं एक मॉडल के लिए, फिर उसका नाम बदलकर B . रख दें , और फिर makemigrations run चलाएँ , फिर Django B . नामक फ़ील्ड जोड़ने के लिए एक नया माइग्रेशन बनाएगा ।

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

• Django माइग्रेशन आपसे नियमों के अनुसार चलने की अपेक्षा करता है: जब आप कुछ भी अनपेक्षित करते हैं, जैसे बोर्ड से एक यादृच्छिक टुकड़ा लेना या नोट्स के साथ खिलवाड़ करना, तो हो सकता है कि ग्रैंडमास्टर पहले नोटिस न करें, लेकिन देर-सबेर, वह अपना हाथ ऊपर कर देगी और जारी रखने से इंकार कर देगी। ऐसा ही तब होता है जब आप django_migrations . के साथ खिलवाड़ करते हैं उदाहरण के लिए किसी मॉडल के लिए डेटाबेस तालिका को हटाकर तालिका या अपने डेटाबेस स्कीमा को माइग्रेशन के बाहर बदलें।

SeparateDatabaseAndState को समझना

अब जब आप Django द्वारा बनाई गई परियोजना स्थिति के बारे में जानते हैं, तो यह ऑपरेशन SeparateDatabaseAndState पर करीब से नज़र डालने का समय है। . यह ऑपरेशन ठीक वही कर सकता है जो नाम का तात्पर्य है:यह प्रोजेक्ट स्थिति (मानसिक मॉडल Django बनाता है) को आपके डेटाबेस से अलग कर सकता है।

SeparateDatabaseAndState संचालन की दो सूचियों के साथ त्वरित किया गया है:

1. state_operations इसमें ऐसे ऑपरेशन शामिल हैं जो केवल प्रोजेक्ट स्थिति पर लागू होते हैं।
2. database_operations इसमें ऑपरेशन होते हैं जो केवल डेटाबेस पर लागू होते हैं।

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

SeparateDatabaseAndState एक उन्नत ऑपरेशन है और आपको अपने पहले दिन माइग्रेशन के साथ काम करने की आवश्यकता नहीं होगी और शायद कभी भी नहीं। SeparateDatabaseAndState हृदय शल्य चिकित्सा के समान है। इसमें काफी जोखिम भरा होता है और यह ऐसा कुछ नहीं है जिसे आप केवल मनोरंजन के लिए करते हैं, बल्कि कभी-कभी रोगी को जीवित रखने के लिए यह एक आवश्यक प्रक्रिया है।

निष्कर्ष

यह Django माइग्रेशन में आपके गहरे गोता लगाने का समापन करता है। बधाई हो! आपने बहुत सारे उन्नत विषयों को कवर कर लिया है और अब आपको एक ठोस समझ है कि माइग्रेशन के अंतर्गत क्या होता है।

आपने सीखा कि:

• Django, Django माइग्रेशन टेबल में लागू किए गए माइग्रेशन का ट्रैक रखता है।
• Django माइग्रेशन में एक migrations . वाली प्लेन पायथन फ़ाइलें होती हैं कक्षा।
• Django जानता है कि operations . से कौन से परिवर्तन करने हैं migrations . में सूची कक्षाएं।
• Django आपके मॉडल की तुलना उस प्रोजेक्ट स्थिति से करता है जिसे वह माइग्रेशन से बनाता है।

इस ज्ञान के साथ, अब आप Django माइग्रेशन पर श्रृंखला के तीसरे भाग से निपटने के लिए तैयार हैं, जहां आप सीखेंगे कि अपने डेटा में एक बार के परिवर्तन सुरक्षित रूप से करने के लिए डेटा माइग्रेशन का उपयोग कैसे करें। बने रहें!

इस लेख में bitcoin_tracker . का इस्तेमाल किया गया है Django प्रवासन में निर्मित Django परियोजना:एक प्राइमर। आप उस लेख के माध्यम से काम करके उस प्रोजेक्ट को फिर से बना सकते हैं या आप स्रोत कोड डाउनलोड कर सकते हैं:

स्रोत कोड डाउनलोड करें: इस लेख में आप जिस Django माइग्रेशन प्रोजेक्ट का उपयोग करेंगे उसका कोड डाउनलोड करने के लिए यहां क्लिक करें।