Django प्रवासन की हत्या

Question

मुझे Django के साथ काफी भरोसा है, लेकिन हाल ही में जेनरेट माइग्रेशन पर अधिक निर्भर है। मैंने एक छोटा सा कस्टम माइग्रेशन लिखा, और मेरे सीआई ने टाइमआउट के बारे में शिकायत शुरू करने के कुछ ही समय बाद और यह समाप्त हो गया कि इसे तैनाती के दौरान Django से माइग्रेशन के साथ कुछ करना था।

सबसे पहले, मैं इस मुद्दे को ठीक करने में सक्षम था, लेकिन मुझे नहीं पता कि मैंने क्या किया (अगर कुछ भी) जिसने इसे मरम्मत की। यह मुद्दा कुछ कस्टम कोड से संबंधित प्रतीत होता है जो मैं एक विशिष्ट माइग्रेशन के लिए प्रवेश कर रहा था। प्रारंभ में, सब किया गया था ठीक

• , लेकिन माइग्रेशन एक वास्तव में लंबे समय (अपेक्षाकृत) अपने कस्टम कोड जोड़ने के बाद चलाने के लिए करना शुरू कर दिया: यहाँ मैं क्या पता है। समय पर लगभग 10 सेकंड।
• यह कभी-कभी काम करता है। अर्थात। यदि मैं कमांड लाइन से दस बार माइग्रेशन चलाता हूं, तो कभी-कभी यह काम करेगा और कभी-कभी यह असफल हो जाएगा।

  [web@dev myapp]$ ./manage.py migrate 
  Operations to perform: 
      Apply all migrations: myapp1, myapp2, myapp3, myapp4 
  Running migrations: 
  Killed 
  

  • पहले तो मैंने सोचा कि यह गया था क्योंकि मैंने पहले दो क्षेत्रों के बीच कि प्रतियां डेटा एक अजगर समारोह को चलाने के लिए RunPython उपयोग कर रहा हूँ:

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

• यहां व्यवसाय परिदृश्य यह है कि मेरे पास एक बुलियन फ़ील्ड था जिसे मुझे विकल्पों के एक सेट पर स्विच करने की आवश्यकता थी (options के साथ चारफिल्ड)। कोड जांचता है कि क्या बूलियन सत्य था और चरित्र फ़ील्ड के लिए सही मान सेट करता है। मैंने इसे दो बार किया है। पहली बार अंततः काम खत्म हो गया, लेकिन मैंने अभी तक इसे किसी अन्य डेटाबेस पर परीक्षण नहीं किया है।

इस माइग्रेशन है (एप्लिकेशन के नाम बाहर संपादित):

from __future__ import unicode_literals 

from django.db import migrations 

def fix_consulting(apps, schema_editor): 
    my_model = apps.get_model("myapp", "MyModel") 
    for m in my_model._default_manager.all(): 
     if m.consulting: 
      m.detail = "CONSLT" 
      m.save() 


class Migration(migrations.Migration): 

    dependencies = [ 
     ('myapp', '0024_auto_20160117_1113'), 
    ] 

    operations = [ 
     migrations.RunPython(fix_consulting,atomic=False), 
    ] 

मेरे विचार:

• हो सकता है कि कोड मैं यहाँ लिख रहा हूँ भी चलाने के लिए समय ले रहा है? डेटाबेस में एक सौ से भी कम मॉडल हैं इसलिए मुझे नहीं पता कि fix_consulting फ़ंक्शन इतना लंबा क्यों लगेगा।

• यदि मैं fix_consulting की शुरुआत में प्रिंट स्टेटमेंट जोड़ता हूं, तो वे केवल कभी-कभी दौड़ते हैं, और अन्य बार मारे जाते हैं। यह खड़ा के रूप में, मैं इसे 6-8 बार भाग गया है और यह हर बार की मौत हो गई है, लेकिन अलग-अलग बिंदुओं

अन्य जानकारी पर: - PostgreSQL 9.4.4 का उपयोग करना - - Django 1.9 का उपयोग करते हुए त्रुटि ज्यादातर CentOS पर होता है, लेकिन ओएसएक्स

Answer 1

मेरा मानना ​​है कि आपकी समस्या उस डेटा की मात्रा के कारण हुई थी जिसे आपको all का उपयोग करते समय कैश करने की आवश्यकता हो सकती है क्योंकि यह किसी ऑब्जेक्ट के सभी उदाहरण देता है, इसलिए आप डेटाबेस पर फ़िल्टरिंग कर सकते हैं ऑब्जेक्ट्स लौटने से पहले स्तर, क्योंकि तब आपको केवल उस फ़ील्ड के मानों को बदलने की आवश्यकता होती है, जो आप डेटाबेस स्तर पर भी कर सकते हैं। कुल मिलाकर यह आपके कोड को निम्नलिखित में बदल देगा।

def fix_consulting(apps, schema_editor): 
    my_model = apps.get_model("myapp", "MyModel") 
    my_model._default_manager.filter(consulting=True).update(detail="CONSLT") 

यह डेटाबेस पर स्मृति प्रबंधन जिम्मेदारियां डालता है जो आपके मुद्दे को हल करने के लिए प्रतीत होता है। (हो सकता है कि स्प्लिसिंग या छानने से)

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