खोज…


पैरामीटर

django-admin कमांड विवरण
makemigrations <my_app> my_app लिए माइग्रेशन उत्पन्न करें
makemigrations सभी ऐप्स के लिए माइग्रेशन उत्पन्न करें
makemigrations --merge सभी एप्लिकेशन के लिए माइग्रेशन विरोध हल करें
makemigrations --merge <my_app> my_app लिए माइग्रेशन विरोध हल करें
makemigrations --name <migration_name> <my_app> my_app नाम migration_name name के लिए माइग्रेशन जनरेट करें
migrate <my_app> डेटाबेस में my_app लंबित माइग्रेशन लागू करें
migrate डेटाबेस के लिए सभी लंबित माइग्रेशन लागू करें
migrate <my_app> <migration_name> लागू करें या migration_name तक अनपेक्षित रूप से करें
migrate <my_app> zero Unapply में सभी माइग्रेशन my_app
sqlmigrate <my_app> <migration_name> नामित प्रवासन के लिए SQL प्रिंट करता है
showmigrations सभी ऐप्स के लिए सभी माइग्रेशन दिखाता है
showmigrations <my_app> my_app में सभी माइग्रेशन दिखाता है

पलायन के साथ काम करना

Django अपने डेटाबेस में अपने मॉडल में किए गए परिवर्तनों का प्रचार करने के लिए माइग्रेशन का उपयोग करता है। अधिकांश समय django उन्हें आपके लिए उत्पन्न कर सकता है।

माइग्रेशन बनाने के लिए, चलाएं:

$ django-admin makemigrations <app_name>

यह app_name के migration app_name में माइग्रेशन फ़ाइल app_name । पहले माइग्रेशन को 0001_initial.py नाम दिया 0001_initial.py , दूसरा 0002_ से शुरू होगा, फिर 0003 , ...

यदि आप <app_name> छोड़ देते हैं, तो यह आपके सभी INSTALLED_APPS लिए माइग्रेशन बनाएगा।

अपने डेटाबेस में माइग्रेशन प्रचारित करने के लिए:

$ django-admin migrate <app_name>

अपने सभी माइग्रेशन दिखाने के लिए, दौड़ें:

$ django-admin showmigrations app_name
app_name
  [X] 0001_initial
  [X] 0002_auto_20160115_1027
  [X] 0003_somemodel
  [ ] 0004_auto_20160323_1826
  • [X] अर्थ है कि माइग्रेशन आपके डेटाबेस में प्रचारित किया गया था
  • [ ] अर्थ है कि माइग्रेशन आपके डेटाबेस में प्रचारित नहीं किया गया था। इसका प्रचार django-admin migrate लिए django-admin migrate का उपयोग करें

आप माइग्रेशन को वापस भी करते हैं, यह migrate command नाम को migrate command पास करके किया जा सकता है। पलायन की उपरोक्त सूची को देखते हुए ( django-admin showmigrations द्वारा दिखाया गया है):

$ django-admin migrate app_name 0002  # Roll back to migration 0002
$ django-admin showmigrations app_name
app_name
  [X] 0001_initial
  [X] 0002_auto_20160115_1027
  [ ] 0003_somemodel
  [ ] 0004_auto_20160323_1826

मैनुअल माइग्रेशन

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

उदाहरण के लिए, आइए आपके पास ऐसे मॉडल हैं:

class Article(models.Model):
    title = models.CharField(max_length=70)

इस मॉडल में पहले से मौजूद डेटा है और अब आप एक SlugField जोड़ना चाहते हैं:

class Article(models.Model):
    title = models.CharField(max_length=70)
    slug = models.SlugField(max_length=70)

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

बेशक, आप टर्मिनल में ऐसा कुछ कर सकते हैं:

$ django-admin shell
>>> from my_app.models import Article
>>> from django.utils.text import slugify
>>> for article in Article.objects.all():
...     article.slug = slugify(article.title)
...     article.save()
...
>>>

लेकिन आपको अपने सभी वातावरणों (यानी आपके कार्यालय के डेस्कटॉप, आपके लैपटॉप, ...) में ऐसा करना होगा, आपके सभी सहकर्मियों को भी ऐसा करना होगा, और आपको मंचन के बारे में सोचना होगा और जब धक्का देना होगा लाइव।

इसे एक बार और सभी के लिए बनाने के लिए, हम इसे एक माइग्रेशन में करेंगे। पहले खाली माइग्रेशन बनाएँ:

$ django-admin makemigrations --empty app_name

यह एक खाली माइग्रेशन फ़ाइल बनाएगा। इसे खोलें, इसमें एक बेस कंकाल है। मान लें कि आपके पिछले माइग्रेशन का नाम 0023_article_slug रखा गया था और इसका नाम 0024_auto_20160719_1734 । यहाँ हम अपनी माइग्रेशन फ़ाइल में लिखेंगे:

# -*- coding: utf-8 -*-
# Generated by Django 1.9.7 on 2016-07-19 15:34
from __future__ import unicode_literals

from django.db import migrations
from django.utils.text import slugify


def gen_slug(apps, schema_editor):
    # We can't import the Article model directly as it may be a newer
    # version than this migration expects. We use the historical version.
    Article = apps.get_model('app_name', 'Article')
    for row in Article.objects.all():
        row.slug = slugify(row.name)
        row.save()


class Migration(migrations.Migration):

    dependencies = [
        ('hosting', '0023_article_slug'),
    ]

    operations = [
        migrations.RunPython(gen_slug, reverse_code=migrations.RunPython.noop),
        # We set `reverse_code` to `noop` because we cannot revert the migration
        # to get it back in the previous state.
        # If `reverse_code` is not given, the migration will not be reversible,
        # which is not the behaviour we expect here.
    ]

नकली पलायन

जब कोई माइग्रेशन चलाया जाता है, तो Django एक django_migrations तालिका में माइग्रेशन का नाम संग्रहीत करता है।

मौजूदा स्कीमा के लिए प्रारंभिक माइग्रेशन बनाएं और बनाएं

यदि आपके ऐप में पहले से ही मॉडल और डेटाबेस टेबल हैं, और माइग्रेशन नहीं है। पहले आप ऐप के लिए प्रारंभिक माइग्रेशन बनाएं।

python manage.py makemigrations your_app_label

अब लागू होने पर नकली प्रारंभिक माइग्रेशन

python manage.py migrate --fake-initial

सभी ऐप में सभी माइग्रेशन को नकली करें

python manage.py migrate --fake

फेक सिंगल ऐप माइग्रेशन

python manage.py migrate --fake core

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

python manage.py migrate myapp migration_name

माइग्रेशन फ़ाइलों के लिए कस्टम नाम

एक उत्पन्न नाम का उपयोग करने के बजाय माइग्रेशन (नामों) के नामकरण की अनुमति देने के लिए makemigrations --name <your_migration_name> विकल्प का उपयोग करें।

python manage.py makemigrations --name <your_migration_name> <app_name>

माइग्रेशन संघर्ष हल करना

परिचय

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

आम माइग्रेशन संघर्ष स्रोत नियंत्रण का उपयोग करते समय होता है, खासकर जब सुविधा-प्रति-शाखा पद्धति का उपयोग किया जाता है। इस परिदृश्य के लिए हम विशेषताओं name और address साथ Reporter नामक एक मॉडल का उपयोग करेंगे।

इस बिंदु पर दो डेवलपर्स एक सुविधा विकसित करने जा रहे हैं, इस प्रकार वे दोनों Reporter मॉडल की प्रारंभिक प्रतिलिपि प्राप्त करते हैं। डेवलपर A एक age जोड़ता है जिसका परिणाम 0002_reporter_age.py फ़ाइल है। डेवलपर B एक bank_account फ़ील्ड जोड़ता है जो 0002_reporter_bank_account में फिर से 0002_reporter_bank_account । एक बार इन डेवलपर्स ने अपने कोड को एक साथ मर्ज कर दिया और माइग्रेशन को स्थानांतरित करने का प्रयास किया, तो एक माइग्रेशन संघर्ष हुआ।

यह विरोध इसलिए होता है क्योंकि ये माइग्रेशन दोनों एक ही मॉडल, Reporter को बदल देते हैं। उसके ऊपर, नई फाइलें दोनों 0002 से शुरू होती हैं।

पलायन को कम करना

इसे करने के कई तरीके हैं। निम्नलिखित अनुशंसित क्रम में है:

  1. इसके लिए सबसे सरल सुधार है - मेमेरीग्रेशन कमांड को --मरज ध्वज के साथ चलाना।

    python manage.py makemigrations --merge <my_app>
    

    यह पिछले संघर्ष को हल करने वाला एक नया प्रवासन बनाएगा।

  2. जब यह अतिरिक्त फ़ाइल व्यक्तिगत कारणों से विकास के वातावरण में स्वागत नहीं है, तो एक विकल्प परस्पर विरोधी पलायन को हटाने के लिए है। फिर, एक नियमित makemigrations कमांड का उपयोग करके एक नया माइग्रेशन बनाया जा सकता है। जब कस्टम माइग्रेशन लिखे जाते हैं, जैसे कि migrations.RunPython , इस विधि का उपयोग करने के लिए जिम्मेदार होना चाहिए।

एक CharField को एक विदेशीके में बदलें

सबसे पहले, आइए मान लें कि यह आपका प्रारंभिक मॉडल है, जिसमें एक एप्लिकेशन है जिसे discography कहा जाता है:

from django.db import models

class Album(models.Model):
    name = models.CharField(max_length=255)
    artist = models.CharField(max_length=255)

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

चरण 1, फॉरेनके के लिए एक नया क्षेत्र जोड़ें, इसे शून्य के रूप में चिह्नित करना सुनिश्चित करें (ध्यान दें कि जिस मॉडल को हम लिंक कर रहे हैं वह भी अब शामिल है):

from django.db import models

class Album(models.Model):
    name = models.CharField(max_length=255)
    artist = models.CharField(max_length=255)
    artist_link = models.ForeignKey('Artist', null=True)

class Artist(models.Model):
    name = models.CharField(max_length=255)

... और इस परिवर्तन के लिए एक प्रवास बनाएँ।

./manage.py makemigrations discography

चरण 2, अपने नए क्षेत्र को आबाद करें। ऐसा करने के लिए, आपको एक खाली माइग्रेशन बनाना होगा।

./manage.py makemigrations --empty --name transfer_artists discography

एक बार जब आपके पास यह खाली माइग्रेशन होता है, तो आप अपने रिकॉर्ड को लिंक करने के लिए इसमें एक एकल RunPython ऑपरेशन जोड़ना चाहते हैं। इस मामले में, यह कुछ इस तरह दिख सकता है:

def link_artists(apps, schema_editor):
    Album = apps.get_model('discography', 'Album')
    Artist = apps.get_model('discography', 'Artist')
    for album in Album.objects.all():
        artist, created = Artist.objects.get_or_create(name=album.artist)
        album.artist_link = artist
        album.save()

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

अपने पहले प्रवास के लिए, आप अपने मूल क्षेत्र, artist को हटाना चाहेंगे। अपने दूसरे माइग्रेशन के लिए, नए क्षेत्र का नाम बदलने artist_link के artist

यह सुनिश्चित करने के लिए कई चरणों में किया जाता है कि Django संचालन को ठीक से पहचानता है।



Modified text is an extract of the original Stack Overflow Documentation
के तहत लाइसेंस प्राप्त है CC BY-SA 3.0
से संबद्ध नहीं है Stack Overflow