Django दक्षिण का उपयोग करके माइग्रेशन इतिहास रीसेट करने के लिए अनुशंसित तरीका क्या है?


153

मैंने साउथ (0.7) और Django (1.1.2) का उपयोग करके कुछ माइग्रेशन जमा किए हैं जो मेरी यूनिट परीक्षणों में काफी समय का उपभोग करना शुरू कर रहे हैं। मैं बेसलाइन को रीसेट करना चाहूंगा और माइग्रेशन का एक नया सेट शुरू करूंगा। मैंने दक्षिण प्रलेखन की समीक्षा की है, सामान्य रूप से Google / Stackoverflow खोज की है (उदाहरण के लिए "django दक्षिण (रीसेट या हटाएं या हटाएं) माइग्रेशन इतिहास") और कुछ भी स्पष्ट नहीं मिला है।

एक दृष्टिकोण जिस पर मैंने विचार किया है, उसमें दक्षिण को "हटाकर" शुरू करना "शामिल" होगा या इतिहास को मैन्युअल रूप से "साफ़ करना" (उदाहरण के लिए db तालिका को साफ़ करना, माइग्रेशन निदेशक से माइग्रेशन फ़ाइलों को हटाना) और बस फिर से चलाना,

./manage.py schemam माइग्रेशन साउथट्यूट - इन-साइट

इसलिए, यदि किसी ने पहले भी ऐसा किया है और उसके पास कुछ सुझाव / सुझाव हैं, तो उनकी बहुत सराहना की जाएगी।


कभी-कभी आपको __init__.pyappname/migrations
laike9m

2
आप 1.7 में माइग्रेशन कैसे रीसेट करते हैं (अंतर्निहित माइग्रेशन के साथ)?
टिमो

1
@Timo: docs.djangoproject.com/en/dev/topics/migrations/… एक दृष्टिकोण हो सकता है। तुम भी बस अपने माइग्रेशन / निर्देशिका और फिर से जारी कर सकते हैं ./manage.py makemigrationsलेकिन अगर आप एक ताजा DB से शुरू नहीं करते हैं तो बुरी चीजें होंगी ...
Jocelyn delalande

मुझे लगता squashmigrationsहै कि सही उत्तर है
जूलियो मरींस

जवाबों:


121

EDIT - मैं इस पर सबसे ऊपर एक टिप्पणी नीचे रख रहा हूं, क्योंकि इसे पहले पढ़ने के लिए महत्वपूर्ण है> स्वीकृत उत्तर जो @andybak के बाद आता है

@ मुख्य: दक्षिण दिशा में रीसेट करने के बारे में आपकी सलाह खतरनाक है और डेटाबेस को नष्ट कर सकता है यदि परियोजना में दक्षिण का उपयोग करने वाले किसी भी तीसरे पक्ष के ऐप हैं, जैसा कि नीचे @thnee द्वारा बताया गया है। चूँकि आपके उत्तर में बहुत सारे अपवोट हैं, मैं वास्तव में इसकी सराहना करूँगा यदि आप इसे संपादित कर सकते हैं और इस बारे में कम से कम एक चेतावनी जोड़ सकते हैं, या (और भी बेहतर) इसे @hobs दृष्टिकोण को प्रतिबिंबित करने के लिए बदल सकते हैं (जो बस के रूप में सुविधाजनक है, लेकिन नहीं अन्य ऐप्स को प्रभावित करें) - धन्यवाद! - क्रिस 26 मार्च 13 को 9:09 बजे

नीचे दिया गया उत्तर स्वीकार किया गया:

सबसे पहले, दक्षिण लेखक द्वारा एक उत्तर :

जब तक आप इसे एक साथ सभी तैनाती पर करने का ध्यान रखते हैं, तब तक इसमें कोई समस्या नहीं होनी चाहिए। व्यक्तिगत रूप से, मैं करूँगा:

    rm -r appname/migrations/ 
    ./manage.py reset south 
    ./manage.py convert_to_south appname 

(ध्यान दें कि " reset south" भाग सभी ऐप्स के लिए माइग्रेशन रिकॉर्ड को साफ़ करता है, इसलिए सुनिश्चित करें कि आप या तो सभी ऐप के लिए अन्य दो लाइनें चलाते हैं या चयनकर्ताओं को हटाते हैं)।

convert_to_southअंत में कॉल एक नया माइग्रेशन बनाता है और यह (के बाद से अपने डेटाबेस पहले से ही इसी टेबल है) नकली लागू होता है। प्रक्रिया के दौरान सभी ऐप तालिकाओं को छोड़ने की कोई आवश्यकता नहीं है।

यहाँ मैं अपने देव + उत्पादन सर्वर पर कर रहा हूँ जब मुझे इन सभी अनावश्यक देव पलायन से छुटकारा पाने की आवश्यकता है:

  1. सुनिश्चित करें कि हमारे पास दोनों तरफ समान DB स्कीमा है
  2. दोनों तरफ के प्रत्येक माइग्रेशन फ़ोल्डर को हटाएं
  3. रन ./manage.py दक्षिण को रीसेट करें (जैसा कि पोस्ट कहता है) दोनों तरफ = दक्षिण तालिका साफ़ करता है *
  4. दोनों पक्षों पर .manage.py Convert_to_south (0001 माइग्रेशन फ़ेकिंग )
  5. फिर मैं माइग्रेशन बनाने के लिए पुनः आरंभ कर सकता हूं और माइग्रेशन फ़ोल्डर को अपने सर्वर पर धकेल सकता हूं

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


2
सिर्फ रिकॉर्ड के लिए, दक्षिण लेखक की प्रतिक्रिया इस प्रकार थी: जब तक आप इसे एक साथ सभी तैनाती पर करने का ध्यान रखते हैं, तब तक इसमें कोई समस्या नहीं होनी चाहिए। व्यक्तिगत रूप से, मैं ऐसा करूंगा: rm -r appname / migrations / ./manage.py दक्षिण रीसेट करें ।/manage.py Convert_to_south appname (ध्यान दें कि "रीसेट दक्षिण" भाग सभी ऐप्स के लिए माइग्रेशन रिकॉर्ड साफ़ करता है, इसलिए सुनिश्चित करें कि आप या तो चलाते हैं। सभी ऐप्स के लिए अन्य दो लाइनें या चयनात्मकता हटाएं)।
एड्रियन टिजसेलिंग 14

2
ध्यान दें कि यदि आप तालिकाओं को छोड़ते हैं, तो आपको manage.py schemamigration app name --initialConvert_to_south के बजाय चाहिए।
एड्रियन टिजसेलिंग

7
Django 1.5 के रूप में, "रीसेट" प्रबंधन आदेश चला गया है। इसके बजाय, आप मोटे तौर पर कुछ करना चाहते हैं south.models.MigrationHistory.objects.all().delete()
एंड्रयू बी

13
@Dominique: आपकी सलाह के बारे manage.py reset southमें खतरनाक है और डेटाबेस को नष्ट कर सकता है अगर परियोजना में दक्षिण का उपयोग करने वाले किसी भी तीसरे पक्ष के ऐप हैं, जैसा कि नीचे @thnee द्वारा बताया गया है। चूँकि आपके उत्तर में बहुत सारे अपवोट हैं, मैं वास्तव में इसकी सराहना करूँगा यदि आप इसे संपादित कर सकते हैं और इस बारे में कम से कम एक चेतावनी जोड़ सकते हैं, या (और भी बेहतर) इसे @hobs दृष्टिकोण को प्रतिबिंबित करने के लिए बदल सकते हैं (जो कि बस सुविधाजनक है, लेकिन ऐसा नहीं करता है अन्य ऐप्स को प्रभावित करें) - धन्यवाद!
क्रिस

3
यह इतना उच्च उत्थान क्यों था? आपको अपने साउथ_ माइग्रेशनहॉस्टर टेबल को पूरी तरह से हटा देना चाहिए। यह पूरी तरह से किसी भी आश्रित ऐप को माइग्रेशन के साथ खराब कर देगा जिसे आप स्पर्श नहीं करना चाहते हैं। होब का जवाब सही है।
सेरिन

188

यदि आपको चुनिंदा (केवल एक ऐप के लिए) माइग्रेशन रीसेट करना है जो बहुत लंबा समय ले रहा है, तो यह मेरे लिए काम करता है।

rm <app-dir>/migrations/*
python manage.py schemamigration <app-name> --initial
python manage.py migrate <app-name> 0001 --fake  --delete-ghost-migrations

अपनी फ़ाइल की तरह लाइनें जोड़कर अन्य ऐप्स पर किसी भी निर्भरता को मैन्युअल रूप से पुनर्स्थापित करना न भूलें , जैसा कि नीचे माइग्रेशन क्लास में पहली विशेषता है ।depends_on = (("<other_app_name>", "0001_initial"),("<yet_another_app_name>", "0001_initial"))<app-dir>/migrations/0001_initial.pyclass Migration(SchemaMigration):

फिर आप ./manage.py migrate <app-name> --fake --delete-ghost-migrationsअन्य वातावरण पर, इस SO उत्तर के अनुसार कर सकते हैं । बेशक, यदि आप डिलीट या नकली को नकली करते migrate zeroहैं , तो आपको इस तरह से माइग्रेशन के साथ किसी भी बाएं-ओवर डीबी टेबल को मैन्युअल रूप से हटाना होगा

एक और अधिक परमाणु विकल्प ./manage.py migrate --fake --delete-ghost-migrationsलाइव परिनियोजन सर्वर पर है, जिसके बाद [माय] स्क्वैल्डम है। फिर पाइप को उस डंप में [my] sql उस वातावरण पर रखें जहां आपको माइग्रेटेड, पूरी तरह से आबादी वाले db की आवश्यकता है। दक्षिण बलिदान, मुझे पता है, लेकिन मेरे लिए काम किया।


2
जो मैं वास्तव में चाहता हूं वह है "मॉडल थिंकपैड को सुसमाचार के रूप में लें, और मुझे उस बिंदु से साफ करें"। इस प्रकार एक तैनाती से खरोंच को स्थापित करने की क्षमता को बनाए रखना, या एक मौजूदा तैनाती से काम करना।
ब्रज

1
यही करता है।
होब्स

2
@ हब्स मुझे DependsOnUnknownMigrationनए प्रारंभिक माइग्रेशन को पूरा करने में थोड़ी देर हो रही थी । आपकी टिप्पणी के लिए धन्यवाद, मैं यह पता लगा सकता हूं कि मुझे depends_onइस ऐप को संदर्भित करने वाले कथन को अपडेट करना चाहिए । यह वास्तव में यहाँ सबसे अच्छा जवाब है। धन्यवाद! :)
मनु

55

डोमिनिक गार्डियोला और हॉब्स के जवाबों की बदौलत इसने मुझे एक कठिन समस्या को हल करने में मदद की। हालाँकि समाधान के साथ कुछ मुद्दे हैं, यहाँ इस पर मेरी राय है।

का उपयोग करना manage.py reset southहै एक अच्छा विचार नहीं आप किसी भी है, तो तृतीय पक्ष ऐप्स को दक्षिण का उपयोग करता है, उदाहरण के लिए django-cms(मूल रूप से सब कुछ दक्षिण उपयोग करता है)।

reset south आपके द्वारा इंस्टॉल किए गए सभी ऐप्स के लिए सभी माइग्रेशन इतिहास को हटा देगा।

अब विचार करें कि आप के नवीनतम संस्करण में अपग्रेड करते हैं django-cms, इसमें नए माइग्रेशन जैसे शामिल होंगे 0009_do_something.py। दक्षिण निश्चित रूप से भ्रमित हो जाएगा जब आप बिना कि माइग्रेशन चलाने का प्रयास 0001के माध्यम से 0008स्थानांतरण इतिहास में।

यह बेहतर है कि आप केवल उन ऐप्स को ही सुरक्षित रखें जो आप बनाए रख रहे हैं


सबसे पहले, सुनिश्चित करें कि आपके ऐप्स में डिस्क पर माइग्रेशन और डेटाबेस पर निष्पादित किए गए माइग्रेशन के बीच कोई desync नहीं है। अन्यथा सिरदर्द होगा।

1. मेरे एप्लिकेशन के लिए माइग्रेशन इतिहास हटाएं

sql> delete from south_migrationhistory where app_name = 'my_app';

2. मेरे ऐप्स के लिए माइग्रेशन हटाएं

$ rm -rf my_app/migrations/

3. मेरे ऐप्स के लिए नए प्रारंभिक माइग्रेशन बनाएं

$ ./manage.py schemamigration --initial my_app

4. नकली मेरे ऐप्स के लिए प्रारंभिक माइग्रेशन निष्पादित करते हैं

यह south_migrationhistoryवास्तविक तालिकाओं को छूने के बिना माइग्रेशन सम्मिलित करता है :

$ ./manage.py migrate --fake my_app

चरण 3 और 4 वास्तव में सिर्फ एक लंबा संस्करण है manage.py convert_to_south my_app, लेकिन मैं उत्पादन डेटाबेस को संशोधित करने जैसी नाजुक स्थिति में उस अतिरिक्त नियंत्रण को प्राथमिकता देता हूं।


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

2
यह बहुत ज्यादा है कि हम क्या कर रहे हैं। चरण 4 पर --delete-भूत माइग्रेशन विकल्प का उपयोग करते हैं, तो आपने चरण 1 बाहर छोड़ सकते हैं
tobych

यदि आप उन एप्लिकेशन को स्पष्ट रूप से निर्दिष्ट करना चाहते हैं, जिनमें ./manage.py migrate --fakeआप अन्य एप्लिकेशन को माइग्रेट नहीं करना चाहते हैं, जिनमें माइग्रेशन लंबित हैं।
वादीम

2
@ वादी इसलिए चरण 0: "सुनिश्चित करें कि आपके पास डिस्क पर माइग्रेशन और डेटाबेस पर निष्पादित किए गए माइग्रेशन के बीच कोई वांछनीय नहीं है"।
thnee

@thnee राइट यह शायद ध्यान देने योग्य है कि आप चरण ० में सभी स्थापित एप्स का उल्लेख कर रहे हैं। क्या आप चरण ० प्रदर्शन करने का एक आसान तरीका जानते हैं?
वादीम

7

Thnee (उसका उत्तर देखें) की तरह, हम दक्षिण लेखक (एंड्रयू गॉडविन) के सुझाव के लिए एक सज्जन दृष्टिकोण का उपयोग कर रहे हैं, यहाँ कहीं और उद्धृत किया गया है, और हम उस चीज़ को अलग कर रहे हैं, जो हम तैनाती के दौरान डेटाबेस से करते हैं। , क्योंकि हमें तैनाती को दोहराने योग्य बनाने की आवश्यकता है:

हम कोड में क्या करते हैं:

# Remove all the migrations from the app
$ rm -fR appname/migrations
# Make the first migration (don't touch the database)
$ ./manage.py schemamigration appname --initial

एक बार कोड तैनात होने के बाद हम डेटाबेस के लिए क्या करते हैं

# Fake the migration history, wiping out the rest
$ ./manage.py migrate appname --fake --delete-ghost-migrations

मुझे लगता है कि मैंने सिर्फ वही काम किया है, लेकिन डेटाबेस प्रविष्टियों को हटाने के बजाय --delete_ghoist-migrations का उपयोग करके। आपका रास्ता थोड़ा अच्छा है।
wobbily_col 16

1

यदि आप सिर्फ देव मशीन पर काम कर रहे हैं, तो मैंने एक प्रबंधन आदेश लिखा है जो डोमिनिक ने सुझाया है।

http://balzerg.blogspot.co.il/2012/09/django-app-reset-with-south.html

दक्षिण लेखक के सुझाव के विपरीत, यह दक्षिण का उपयोग करने वाले अन्य इंस्टॉल किए गए ऐप्स को HARM नहीं करेगा।


और अगर, लेखक के विपरीत, आप मौजूदा माइग्रेशन रखना चाहते हैं (यानी आप ऐप के साथ-साथ माइग्रेशन हिस्ट्री भी रीसेट करना चाहते हैं, लेकिन वास्तविक माइग्रेशन रखना चाहते हैं), तो आप यह कोशिश कर सकते हैं: goo.gl/0ZnWm
mgalx

1

इसके बाद ही आप सभी ऐप्स को रीसेट करना चाहते हैं। कृपया उस काम से पहले अपने सभी डेटाबेस का बैकअप लें। यदि कोई हो, तो प्रारंभिक फ़ाइलों में अपने depend_on को भी नोट करें ।

एक बार के लिए:

(1) find . -type d -name migrations -exec git rm -rf '{}' \;
(2) find . -type d -name migrations -exec rm -rf '{}' \;
(3) ./manage.py schemamigration <APP_NAME> --initial
(4) [GIT COMMIT]

पुश से पहले अपनी परियोजना बूटस्ट्रैपिंग का परीक्षण करें। फिर, प्रत्येक स्थानीय / दूरस्थ मशीन के लिए, निम्नलिखित आवेदन करें:

(5) [GIT PULL]
(6) ./manage.py reset south
(7) ./manage.py migrate --fake

उस प्रत्येक ऐप के लिए प्रारंभिक (3) करें जिसे आप फिर से शामिल करना चाहते हैं। ध्यान दें कि, रीसेट (6) केवल माइग्रेशन इतिहास को हटा देगा, इसलिए पुस्तकालयों के लिए हानिकारक नहीं है। नकली माइग्रेशन (7) स्थापित किए गए किसी भी 3 पार्टी ऐप्स के माइग्रेशन इतिहास को वापस रख देगा।


हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.