Django

Question

में डेटाबेस टेबल को बदलना मैं एक परियोजना के लिए Django का उपयोग करने पर विचार कर रहा हूं (fyi, एक ब्राउज़र-आधारित गेम) और सबसे अधिक सुविधाओं में से एक है जो syncdb का उपयोग कर डेटाबेस टेबल स्वचालित रूप से बनाने के लिए है Django मॉडल के आधार पर मैं परिभाषित करता हूं (एक सुविधा जिसे मैं किसी अन्य ढांचे में नहीं ढूंढ सकता)। मैं पहले से ही सोच रहा था जब मैं documentation में यह देखा यह वास्तव में बहुत ही अच्छा था:

Syncdb मौजूदा टेबल

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

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

ऐसा लगता है कि मौजूदा तालिकाओं को बदलने से "हाथ से" किया जाना होगा।

जो मैं जानना चाहता हूं वह ऐसा करने का सबसे अच्छा तरीका है। दो समाधान दिमाग में आते हैं:

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

कोई विचार?

Answer 1

एक ही विषय के लिए अन्य उत्तर में बताया गया है, यूट्यूब पर DjangoCon 2008 Schema Evolution Panel देखने के लिए सुनिश्चित करें। नक्शे पर

इसके अलावा, दो नई परियोजनाओं: Simplemigrations और Migratory।

Answer 2

मैन्युअल एसक्यूएल परिवर्तन कर रहे हैं और डंप/पुनः लोड दोनों विकल्प हैं, लेकिन आप यह भी Django के लिए स्कीमा-विकास संकुल में से कुछ की जाँच कर सकते हैं। सबसे परिपक्व विकल्प django-evolution और South हैं।

संपादित करें: और हे, यहां dmigrations आता है।

अद्यतन: के बाद से इस सवाल का जवाब मूल रूप से लिखा गया था, django-evolution और dmigrations दोनों सक्रिय विकास और South Django में स्कीमा माइग्रेशन के लिए वास्तविक मानक बन गया है रह गए है। दक्षिण की कुछ हिस्सों को अगले रिलीज या दो में डीजेगो में भी एकीकृत किया जा सकता है।

अद्यतन: एक स्कीमा-माइग्रेशन ढांचे दक्षिण के आधार पर (और एंड्रयू गोडविन, दक्षिण के लेखक द्वारा लेखक) Django 1.7+ में शामिल है। यह करने के लिए

Answer 3

एक अच्छा तरीका जुड़नार, विशेष रूप से initial_data जुड़नार के माध्यम से है।

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

आप django-admin.py dumpdata का उपयोग कर अपने DB में वर्तमान में डेटा से एक दृढ़ बना सकते हैं। डिफ़ॉल्ट रूप से डेटा जेएसओएन प्रारूप में है, लेकिन एक्सएमएल जैसे अन्य विकल्प उपलब्ध हैं। फिक्स्चर स्टोर करने के लिए एक अच्छी जगह fixtures आपकी एप्लिकेशन निर्देशिकाओं की उप-निर्देशिका है।

आप एक fixure django-admin.py loaddata लेकिन का उपयोग कर लोड कर सकते हैं और अधिक महत्वपूर्ण है, अपने दृढ़ initial_data.json की तरह एक नाम यह स्वचालित रूप से लोड किया जाएगा जब आप एक syncdb करते हैं, यह अपने आप को आयात करने की मुसीबत बचत है या नहीं।

एक और लाभ यह है कि जब आप manage.py test चलाने के लिए अपनी यूनिट को चलाने के लिए टेस्ट अस्थायी परीक्षण डेटाबेस भी प्रारंभिक डेटा स्थिरता लोड होगा।

बेशक

, यह काम जब जब आप मॉडल और स्तंभों डीबी करने के लिए गुण जोड़ रहे होंगे। यदि आप डेटाबेस से एक कॉलम ड्रॉप करते हैं तो आपको उस कॉलम के डेटा को निकालने के लिए अपने स्थिरता को अपडेट करना होगा जो सीधा नहीं हो सकता है।

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

Answer 4

मैं django-evolution का उपयोग कर रहा हूं। चेतावनियां शामिल हैं:

• इसकी स्वचालित सुझावों समान रूप से सड़ा हुआ है; और
• इसका फिंगरप्रिंट फ़ंक्शन अलग-अलग प्लेटफ़ॉर्म पर एक ही डेटाबेस के लिए अलग-अलग मान देता है।

यही कहा, मैं कस्टम schema_evolution.py दृष्टिकोण काम पाते हैं।

BEFORE = 'fv1:-436177719' # first fingerprint 
BEFORE64 = 'fv1:-108578349625146375' # same, but on 64-bit Linux 
AFTER = 'fv1:-2132605944' 
AFTER64 = 'fv1:-3559032165562222486' 

fingerprints = [ 
    BEFORE, AFTER, 
    BEFORE64, AFTER64, 
    ] 

CHANGESQL = """ 
    /* put your SQL code to make the changes here */ 
    """ 

evolutions = [ 
    ((BEFORE, AFTER), CHANGESQL), 
    ((BEFORE64, AFTER64), CHANGESQL) 
    ] 

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

संपादित करें: यह देखते हुए कि मैं मैन्युअल रूप से अपने परिवर्तनों का निर्माण कर रहा हूं, मैं अगली बार dmigrations आज़माउंगा।

Answer 5

django-command-extensions एक Django पुस्तकालय कि manage.py को कुछ अतिरिक्त आदेशों देता है। उनमें से एक sqldiff है, जो आपको अपने नए मॉडल को अद्यतन करने के लिए आवश्यक एसक्यूएल देना चाहिए। हालांकि, यह 'बहुत प्रयोगात्मक' के रूप में सूचीबद्ध है।

Answer 6

अभी तक मेरी कंपनी में हमने मैन्युअल दृष्टिकोण का उपयोग किया है। आपके लिए सबसे अच्छा क्या काम करता है आपकी विकास शैली पर बहुत निर्भर करता है।

हमारे पास आम तौर पर उत्पादन प्रणालियों में कई स्कीमा परिवर्तन नहीं होते हैं और कुछ हद तक औपचारिक रोलआउट विकास से उत्पादन सर्वर तक होते हैं। जब भी हम रोल आउट करते हैं (साल में 10-20 बार) हम वर्तमान कोड की समीक्षा करते हैं और आने वाली उत्पादन शाखा सभी कोड की समीक्षा करते हैं और यह देखते हुए कि उत्पादन सर्वर पर क्या बदला जाना है। आवश्यक परिवर्तन अतिरिक्त निर्भरता, सेटिंग फ़ाइल में परिवर्तन और डेटाबेस में परिवर्तन हो सकते हैं।

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

Answer 7

Django पुस्तक बताती है कि हाथ से इसे कैसे किया जाए।

http://www.djangobook.com/en/2.0/chapter10/

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

मैंने हाल ही में दक्षिण का उपयोग शुरू किया। यह थोड़ा कम लचीला लगता है (या शायद मुझे दस्तावेज़ों को और कुछ पढ़ने की जरूरत है।) लेकिन आपको थोड़ा सा टाइपिंग बचा सकता है। कभी-कभी आप डेटाबेस के साथ सिंक से बाहर निकलने का प्रबंधन करते हैं, जो एक दुःस्वप्न है। ऐसा लगता है जब तक आप इसे इस्तेमाल करते रहें। ऐसा लगता है कि यह मॉडल और वास्तविक डेटाबेस को एक साथ जोड़ता है, जो आपकी स्थिति

Answer 8

Django 1.7 (वर्तमान में विकास में) के आधार पर एक अच्छी बात हो सकती है या नहीं हो सकती है। manage.py migrate और manage.py makemigrations (migratesyncdb से बाहर) के साथ स्कीमा माइग्रेशन के लिए है।