Django 2.1 - Migration Operations

प्रवासन संचालन




django

प्रवासन संचालन

माइग्रेशन फाइलें एक या एक से अधिक Operation एस से बनी होती हैं, ऐसी वस्तुएं जो घोषित रूप से रिकॉर्ड करती हैं कि माइग्रेशन आपके डेटाबेस में क्या करना चाहिए।

Django इन Operation ऑब्जेक्ट्स का उपयोग यह जानने के लिए भी करता है कि आपके मॉडल ऐतिहासिक रूप से क्या दिखते हैं, और यह गणना करने के लिए कि आपके मॉडल में अंतिम प्रवास के बाद से आपके द्वारा किए गए बदलाव क्या हैं ताकि यह स्वचालित रूप से आपके माइग्रेशन लिख सके; यही कारण है कि वे घोषणात्मक हैं, क्योंकि इसका मतलब है कि Django आसानी से उन सभी को मेमोरी में लोड कर सकता है और डेटाबेस को छूने के बिना उनके माध्यम से चला सकता है ताकि आपकी परियोजना को कैसा दिखना चाहिए।

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

यदि आपको अपने स्वयं के Operation ऑब्जेक्ट को लिखने के लिए एक खाली माइग्रेशन फ़ाइल की आवश्यकता है, तो बस python manage.py makemigrations --empty yourappname उपयोग करें, लेकिन इस बात से अवगत python manage.py makemigrations --empty yourappname कि स्कीमा-परिवर्तनशील संचालन को जोड़ने से माइग्रेशन makemigrations को भ्रमित किया जा सकता है और इसके परिणामस्वरूप उत्पादन के रन गलत हो सकते हैं कोड।

सभी कोर Django ऑपरेशन django.db.migrations.operations मॉड्यूल से उपलब्ध हैं।

परिचयात्मक सामग्री के लिए, माइग्रेशन विषय मार्गदर्शिका देखें

स्कीमा संचालन

CreateModel

class CreateModel(name, fields, options=None, bases=None, managers=None) [source]

परियोजना के इतिहास में एक नया मॉडल बनाता है और इसे मेल खाने के लिए डेटाबेस में एक संबंधित तालिका।

name मॉडल नाम है, जैसा कि मॉडल models.py फ़ाइल में लिखा जाएगा।

fields 2- (field_name, field_instance) ऑफ़ (field_name, field_instance) की एक सूची है। फ़ील्ड का उदाहरण एक अनबाउंड फ़ील्ड (इसलिए सिर्फ मॉडल होना चाहिए। models.CharField(...) , किसी अन्य मॉडल से लिए गए फ़ील्ड के बजाय)।

options मॉडल के Meta क्लास से मूल्यों का एक वैकल्पिक शब्दकोश है।

bases अन्य वर्गों की एक वैकल्पिक सूची है जो इस मॉडल से विरासत में मिली है; यदि आप किसी अन्य मॉडल पर निर्भर करना चाहते हैं (तो आपको ऐतिहासिक संस्करण से विरासत में मिला है) दोनों वर्ग वस्तुओं के साथ-साथ प्रारूप "appname.ModelName" में तार हो सकते हैं। अगर इसकी आपूर्ति नहीं की जाती है, तो यह मानक models.Model से विरासत में मिला है।

managers ने 2- (manager_name, manager_instance) ऑफ़ (manager_name, manager_instance) एक सूची (manager_name, manager_instance) । माइग्रेशन के दौरान सूची में पहला प्रबंधक इस मॉडल के लिए डिफ़ॉल्ट प्रबंधक होगा।

DeleteModel

class DeleteModel(name) [source]

डेटाबेस से प्रोजेक्ट इतिहास और उसकी तालिका से मॉडल हटाता है।

RenameModel

class RenameModel(old_name, new_name) [source]

पुराने नाम से मॉडल को नया नाम दिया गया।

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

AlterModelTable

class AlterModelTable(name, table) [source]

मॉडल की तालिका नाम ( Meta db_table पर db_table विकल्प) को db_table

AlterUniqueTogether

class AlterUniqueTogether(name, unique_together) [source]

अद्वितीय बाधाओं ( Meta उपवर्ग पर अद्वितीय_पसंद विकल्प) के मॉडल के सेट को unique_together

AlterIndexTogether

class AlterIndexTogether(name, index_together) [source]

कस्टम अनुक्रमणिका के मॉडल के सेट को बदलता है ( Meta उपवर्ग पर index_together विकल्प)।

AlterOrderWithRespectTo

class AlterOrderWithRespectTo(name, order_with_respect_to) [source]

Meta उपवर्ग पर order_with_respect_to विकल्प के लिए आवश्यक _order स्तंभ बनाता या हटाता है।

AlterModelOptions

class AlterModelOptions(name, options) [source]

स्टोर विविध मॉडल विकल्पों (किसी मॉडल के Meta पर सेटिंग) जैसे permissions और verbose_name । डेटाबेस को प्रभावित नहीं करता है, लेकिन RunPython उदाहरणों के उपयोग के लिए इन परिवर्तनों को RunPython options मूल्यों के लिए एक शब्दकोश मानचित्रण विकल्प नाम होना चाहिए।

AlterModelManagers

class AlterModelManagers(name, managers) [source]

उन प्रबंधकों को अलर्ट करता है जो पलायन के दौरान उपलब्ध हैं।

AddField

class AddField(model_name, name, field, preserve_default=True) [source]

एक मॉडल के लिए एक क्षेत्र जोड़ता है। model_name मॉडल का नाम है, name फ़ील्ड का नाम है, और field एक अनबाउंड फ़ील्ड उदाहरण है (वह चीज़ जो आप models.IntegerField(null=True) घोषणा में फ़ील्ड घोषणा में models.py - उदाहरण के लिए, models.IntegerField(null=True)

preserve_default तर्क इंगित करता है कि क्या फ़ील्ड का डिफ़ॉल्ट मान स्थायी है और इसे प्रोजेक्ट स्थिति ( True ) में बेक किया जाना चाहिए, या यदि यह अस्थायी है और सिर्फ इस माइग्रेशन ( False ) के लिए है - आमतौर पर क्योंकि माइग्रेशन नॉन-न्यूलर फ़ील्ड को जोड़ रहा है a तालिका और मौजूदा पंक्तियों में डालने के लिए एक डिफ़ॉल्ट मान की आवश्यकता है। यह डेटाबेस में चूक को सीधे सेट करने के व्यवहार को प्रभावित नहीं करता है - Django डेटाबेस की चूक को कभी सेट नहीं करता है और हमेशा उन्हें Django ORM कोड में लागू करता है।

RemoveField

class RemoveField(model_name, name) [source]

किसी मॉडल से फ़ील्ड निकालता है।

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

AlterField

class AlterField(model_name, name, field, preserve_default=True) [source]

किसी फ़ील्ड की परिभाषा को बदल देता है, जिसमें उसके प्रकार, null , unique , db_column और अन्य फ़ील्ड विशेषताएँ शामिल हैं।

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

ध्यान दें कि सभी डेटाबेस पर सभी परिवर्तन संभव नहीं हैं - उदाहरण के लिए, आप models.TextField() तरह एक पाठ-प्रकार फ़ील्ड नहीं बदल सकते हैं। जैसा कि कई डेटाबेस में नंबर प्रकार फ़ील्ड में models.IntegerField() । अधिकांश डेटाबेस पर models.IntegerField()

RenameField

class RenameField(model_name, old_name, new_name) [source]

फ़ील्ड का नाम बदलता है (और, जब तक db_column सेट नहीं db_column जाता है, उसका कॉलम नाम)।

AddIndex

class AddIndex(model_name, index) [source]

model_name साथ मॉडल के लिए डेटाबेस तालिका में एक सूचकांक बनाता है। index Index क्लास का एक उदाहरण है।

RemoveIndex

class RemoveIndex(model_name, name) [source]

मॉडल से name वाले इंडेक्स को model_name साथ model_name

विशेष संचालन

RunSQL

class RunSQL(sql, reverse_sql=None, state_operations=None, hints=None, elidable=False) [source]

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

यदि प्रदान किया गया है तो sql , और reverse_sql sql डेटाबेस पर चलाने के लिए SQL के तार होना चाहिए। अधिकांश डेटाबेस बैकएंड (सभी लेकिन PostgreSQL) पर, Django SQL को अलग-अलग बयानों में निष्पादित करने से पहले विभाजित करेगा। इसके लिए sqlparse Python पुस्तकालय स्थापित करने की आवश्यकता है।

आप स्ट्रिंग्स या 2-टुपल्स की एक सूची भी पास कर सकते हैं। उत्तरार्द्ध का उपयोग cursor.execute() और cursor.execute() के समान प्रश्नों और मापदंडों को पारित करने के लिए किया जाता है। ये तीन ऑपरेशन बराबर हैं:

migrations.RunSQL("INSERT INTO musician (name) VALUES ('Reinhardt');")
migrations.RunSQL([("INSERT INTO musician (name) VALUES ('Reinhardt');", None)])
migrations.RunSQL([("INSERT INTO musician (name) VALUES (%s);", ['Reinhardt'])])

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

माइग्रेशन के अप्राप्य होने पर reverse_sql प्रश्नों को निष्पादित किया जाता है, इसलिए आप फॉरवर्ड प्रश्नों में किए गए परिवर्तनों को उल्टा कर सकते हैं:

migrations.RunSQL(
    [("INSERT INTO musician (name) VALUES (%s);", ['Reinhardt'])],
    [("DELETE FROM musician where name=%s;", ['Reinhardt'])],
)

state_operations तर्क है, ताकि आप प्रोजेक्ट राज्य के संदर्भ में SQL के बराबर संचालन की आपूर्ति कर सकें; उदाहरण के लिए, यदि आप मैन्युअल रूप से एक कॉलम बना रहे हैं, तो आपको यहां AddField ऑपरेशन वाली एक सूची में पास होना चाहिए ताकि AddField अभी भी मॉडल की अप-टू-डेट स्थिति हो (अन्यथा, जब आप अगली बार makemigrations , तो यह जीत गया ' टी किसी भी ऑपरेशन को देखें जो उस क्षेत्र को जोड़ता है और इसलिए इसे फिर से चलाने की कोशिश करेगा)। उदाहरण के लिए:

migrations.RunSQL(
    "ALTER TABLE musician ADD COLUMN name varchar(255) NOT NULL;",
    state_operations=[
        migrations.AddField(
            'musician',
            'name',
            models.CharField(max_length=255),
        ),
    ],
)

राउटिंग निर्णय लेने में सहायता के लिए वैकल्पिक hints तर्क को डेटाबेस राउटर के allow_migrate() विधि के लिए **hints रूप में पारित किया जाएगा। डेटाबेस संकेत पर अधिक जानकारी के लिए Hints देखें।

वैकल्पिक elidable तर्क यह निर्धारित करता है कि elidable करते समय ऑपरेशन को हटा दिया जाएगा (नहीं)।

RunSQL.noop

जब आप ऑपरेशन को दिए गए दिशा में कुछ नहीं करना चाहते हैं, तो sql या RunSQL.noop sql को RunSQL.noop विशेषता पास करें। यह ऑपरेशन को प्रतिवर्ती बनाने में विशेष रूप से उपयोगी है।

RunPython

class RunPython(code, reverse_code=None, atomic=None, hints=None, elidable=False) [source]

ऐतिहासिक संदर्भ में कस्टम पायथन कोड चलाता है। code (और अगर आपूर्ति की गई reverse_code ) reverse_code योग्य ऑब्जेक्ट होना चाहिए जो दो तर्क स्वीकार करते हैं; पहला django.apps.registry.Apps का एक उदाहरण है, जिसमें ऐतिहासिक मॉडल हैं जो परियोजना के इतिहास में ऑपरेशन के स्थान से मेल खाते हैं, और दूसरा एक SchemaEditor का एक उदाहरण है।

माइग्रेशन अप्राप्त होने पर रिवर्स_कोड तर्क को कहा जाता है। यह कॉल करने योग्य होना चाहिए कि code योग्य में क्या किया जाता है ताकि माइग्रेशन प्रतिवर्ती हो।

वैकल्पिक hints तर्क को डेटाबेस राउटर के allow_migrate() विधि के लिए **hints रूप में पारित किया जाएगा ताकि वे रूटिंग निर्णय लेने में सहायता कर सकें। डेटाबेस संकेत पर अधिक जानकारी के लिए Hints देखें।

वैकल्पिक elidable तर्क यह निर्धारित करता है कि elidable करते समय ऑपरेशन को हटा दिया जाएगा (नहीं)।

आपको माइग्रेशन फ़ाइल में Migration क्लास के ऊपर एक अलग फ़ंक्शन के रूप में कोड लिखने की सलाह दी जाती है, और बस इसे RunPython को पास करें। Country मॉडल पर कुछ प्रारंभिक वस्तुओं को बनाने के लिए RunPython का उपयोग करने का एक उदाहरण है:

from django.db import migrations

def forwards_func(apps, schema_editor):
    # We get the model from the versioned app registry;
    # if we directly import it, it'll be the wrong version
    Country = apps.get_model("myapp", "Country")
    db_alias = schema_editor.connection.alias
    Country.objects.using(db_alias).bulk_create([
        Country(name="USA", code="us"),
        Country(name="France", code="fr"),
    ])

def reverse_func(apps, schema_editor):
    # forwards_func() creates two Country instances,
    # so reverse_func() should delete them.
    Country = apps.get_model("myapp", "Country")
    db_alias = schema_editor.connection.alias
    Country.objects.using(db_alias).filter(name="USA", code="us").delete()
    Country.objects.using(db_alias).filter(name="France", code="fr").delete()

class Migration(migrations.Migration):

    dependencies = []

    operations = [
        migrations.RunPython(forwards_func, reverse_func),
    ]

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

यदि आप दक्षिण से अपग्रेड कर रहे हैं, तो यह मूल रूप से एक ऑपरेशन के रूप में दक्षिण पैटर्न है - एक या दो तरीकों के लिए आगे और पीछे के लिए, एक ORM और स्कीमा ऑपरेशन उपलब्ध हैं। अधिकांश समय, आपको orm.Model या orm["appname", "Model"] का अनुवाद करने में सक्षम होना चाहिए orm["appname", "Model"] दक्षिण से सीधे apps.get_model("appname", "Model") संदर्भों को यहां संदर्भित करें और अधिकांश को छोड़ दें डेटा माइग्रेशन के लिए शेष कोड अपरिवर्तित है। हालाँकि, apps में केवल मौजूदा ऐप में मॉडल के संदर्भ होंगे जब तक कि अन्य ऐप में माइग्रेशन माइग्रेशन की निर्भरता में नहीं जोड़े जाते हैं।

बहुत कुछ RunSQL तरह, सुनिश्चित करें कि अगर आप स्कीमा को यहाँ बदलते हैं, तो आप इसे या तो Django मॉडल सिस्टम के दायरे से बाहर कर रहे हैं (जैसे ट्रिगर) या कि आप संचालन में जोड़ने के लिए SeparateDatabaseAndState का उपयोग करें जो मॉडल स्थिति में आपके परिवर्तनों को प्रतिबिंबित करेगा - अन्यथा संस्करण वाले ORM और ऑटोडेटेक्टर सही ढंग से काम करना बंद कर देंगे।

डिफ़ॉल्ट रूप से, RunPython डेटाबेस पर एक लेनदेन के अंदर अपनी सामग्री चलाएगा जो DDL लेनदेन (उदाहरण के लिए, MySQL और Oracle) का समर्थन नहीं करता है। यह सुरक्षित होना चाहिए, लेकिन यदि आप इन बैकएंड पर schema_editor गए schema_editor का उपयोग करने का प्रयास करते हैं तो दुर्घटना हो सकती है; इस मामले में, atomic=False RunPython ऑपरेशन के लिए atomic=False पास।

डेटाबेस जो DDL लेनदेन (SQLite और PostgreSQL) का समर्थन करते हैं, RunPython संचालन में प्रत्येक माइग्रेशन के लिए किए गए लेन-देन के अलावा स्वचालित रूप से जोड़ा गया कोई लेनदेन नहीं होता है। इस प्रकार, PostgreSQL पर, उदाहरण के लिए, आपको एक ही माइग्रेशन में स्कीमा परिवर्तन और RunPython संचालन के संयोजन से बचना चाहिए या आप RunPython तरह त्रुटियों को मार OperationalError: cannot ALTER TABLE "mytable" because it has pending trigger events

यदि आपके पास एक अलग डेटाबेस है और सुनिश्चित नहीं है कि यह DDL लेनदेन का समर्थन करता है, तो django.db.connection.features.can_rollback_ddl विशेषता की जाँच करें।

यदि RunPython ऑपरेशन एक गैर-परमाणु प्रवासन का हिस्सा है, तो ऑपरेशन केवल एक लेनदेन में निष्पादित किया जाएगा यदि atomic=True RunPython ऑपरेशन में पास हो।

चेतावनी

RunPython आपके लिए मॉडल के कनेक्शन को जादुई रूप से नहीं बदलता है; आपके द्वारा कॉल की जाने वाली कोई भी मॉडल विधि डिफ़ॉल्ट डेटाबेस पर जाएगी जब तक कि आप उन्हें वर्तमान डेटाबेस उपनाम ( schema_editor.connection.alias से उपलब्ध schema_editor.connection.alias , जहां schema_editor आपके फ़ंक्शन का दूसरा तर्क है)।

static RunPython.noop() [source]

जब आप ऑपरेशन को दिए गए दिशा में कुछ भी नहीं करना चाहते, तो RunPython.noop code या RunPython.noop पास करें। यह ऑपरेशन को प्रतिवर्ती बनाने में विशेष रूप से उपयोगी है।

SeparateDatabaseAndState

class SeparateDatabaseAndState(database_operations=None, state_operations=None) [source]

एक अत्यधिक विशिष्ट ऑपरेशन जो आपको डेटाबेस (स्कीमा-चेंजिंग) और ऑपरेशन के स्टेट (ऑटोडेटेक्टर-पॉवरिंग) पहलुओं को मिक्स एंड मैच करता है।

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

अपना खुद का लिखना

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

from django.db.migrations.operations.base import Operation

class MyCustomOperation(Operation):

    # If this is False, it means that this operation will be ignored by
    # sqlmigrate; if true, it will be run and the SQL collected for its output.
    reduces_to_sql = False

    # If this is False, Django will refuse to reverse past this operation.
    reversible = False

    def __init__(self, arg1, arg2):
        # Operations are usually instantiated with arguments in migration
        # files. Store the values of them on self for later use.
        pass

    def state_forwards(self, app_label, state):
        # The Operation should take the 'state' parameter (an instance of
        # django.db.migrations.state.ProjectState) and mutate it to match
        # any schema changes that have occurred.
        pass

    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        # The Operation should use schema_editor to apply any changes it
        # wants to make to the database.
        pass

    def database_backwards(self, app_label, schema_editor, from_state, to_state):
        # If reversible is True, this is called when the operation is reversed.
        pass

    def describe(self):
        # This is used to describe what the operation does in console output.
        return "Custom Operation"

आप इस टेम्प्लेट को ले सकते हैं और उससे काम कर सकते हैं, हालाँकि हम django.db.migrations.operations में django.db.migrations.operations Django संचालन को django.db.migrations.operations सुझाव देते हैं - वे अर्ध-आंतरिक पहलुओं के उदाहरण के उपयोग को पढ़ने और कवर करने में आसान हैं माइग्रेशन फ्रेमवर्क जैसे ProjectState और पैटर्न का उपयोग ऐतिहासिक मॉडल को प्राप्त करने के लिए किया जाता है, साथ ही ModelState और state_forwards() में ऐतिहासिक मॉडलों को बदलने के लिए उपयोग किए जाने वाले पैटर्न।

ध्यान देने योग्य कुछ बातें:

  • आपको सरल माइग्रेशन लिखने के लिए ProjectState बारे में बहुत अधिक जानने की आवश्यकता नहीं है; बस यह जान लें कि इसमें एक apps प्रॉपर्टी है जो ऐप रजिस्ट्री को एक्सेस देता है (जिसे आप तब get_model पर कॉल कर सकते हैं)।
  • database_forwards और database_backwards दोनों को दो राज्य उनके पास दिए जाते हैं; ये बस उस अंतर का प्रतिनिधित्व करते हैं जो state_forwards विधि ने लागू किया होगा, लेकिन आपको सुविधा और गति कारणों से दिया जाता है।
  • यदि आप database_forwards() या database_backwards() से from_state तर्क से मॉडल वर्ग या मॉडल इंस्टेंसेस के साथ काम करना चाहते हैं, तो आपको संबंधित मॉडल उपलब्ध करने के लिए clear_delayed_apps_cache() विधि का उपयोग करके मॉडल राज्यों को प्रस्तुत करना होगा:

    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        # This operation should have access to all models. Ensure that all models are
        # reloaded in case any are delayed.
        from_state.clear_delayed_apps_cache()
        ...
    
  • to_state विधि में to_state पुरानी स्थिति है; यानी प्रवास समाप्त होने के बाद जो वर्तमान स्थिति होगी वह एक है।
  • आप अंतर्निहित कार्यों पर संदर्भ_मॉडल का कार्यान्वयन देख सकते हैं; यह ऑटोडेटेक्शन कोड का हिस्सा है और कस्टम ऑपरेशन के लिए कोई मायने नहीं रखता है।

चेतावनी

प्रदर्शन कारणों से, ModelState.fields में Field आवृत्तियों का पुन: उपयोग माइग्रेशन के दौरान किया जाता है। आपको इन उदाहरणों पर विशेषताओं को कभी नहीं बदलना चाहिए। यदि आपको state_forwards() में किसी फ़ील्ड को state_forwards() करने की आवश्यकता है, तो आपको ModelState.fields से पुराने इंस्टेंस को ModelState.fields और इसके स्थान पर एक नया इंस्टेंस जोड़ना होगा। ModelState.managers में Manager उदाहरणों के लिए भी यही सच है।

एक सरल उदाहरण के रूप में, चलो एक ऑपरेशन बनाते हैं जो PostgreSQL एक्सटेंशन को लोड करता है (जिसमें कुछ PostgreSQL की अधिक रोमांचक विशेषताएं हैं)। यह काफी सरल है; कोई मॉडल राज्य परिवर्तन नहीं है, और यह सब एक कमांड चला रहा है:

from django.db.migrations.operations.base import Operation

class LoadExtension(Operation):

    reversible = True

    def __init__(self, name):
        self.name = name

    def state_forwards(self, app_label, state):
        pass

    def database_forwards(self, app_label, schema_editor, from_state, to_state):
        schema_editor.execute("CREATE EXTENSION IF NOT EXISTS %s" % self.name)

    def database_backwards(self, app_label, schema_editor, from_state, to_state):
        schema_editor.execute("DROP EXTENSION %s" % self.name)

    def describe(self):
        return "Creates extension %s" % self.name