2011-05-31 16 views
10

मान लें कि मेरी मुख्य शाखा (devlop) और मेरी फीचर शाखा दोनों में सक्रिय विकास है। दोनों बार-बार माइग्रेशन जोड़ रहे हैं। फीचर शाखा को मुख्य शाखा में विलय करने से पहले, मैं इसे मुख्य शाखा में पुन: पेश करने जा रहा हूं।फीचर शाखाओं में माइग्रेशन टाइमस्टैम्प अपडेट करना

तो यह सबसे हाल ही में विकसित शाखा प्रवासन के बाद आने वाली सभी फीचर शाखा माइग्रेशन के लिए केवल समझ में आता है।

क्या इन फ़ाइलों का नाम बदलने के लिए कोई आसान/सलाह दी गई है? मैं सिर्फ डमी माइग्रेशन उत्पन्न कर सकता हूं और उनके लिए उत्पन्न टाइमस्टैम्प का पुन: उपयोग कर सकता हूं - लेकिन मुझे आश्चर्य है कि वहां कोई सर्वश्रेष्ठ/सामान्य अभ्यास है जिसके बारे में मुझे नहीं पता?

+1

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

+0

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

+0

अक्सर ऐसा होता है कि लोग शाखा को अद्यतित रखने के लिए ट्रंक से फीचर-शाखा में वापस विलय करते हैं (भयानक विलय से दूसरे तरीके से विलय से बचने के लिए)। तो यह काफी संभव है कि फीचर-शाखा ट्रंक में विकसित कोड पर निर्भर करेगी ... बस दूसरी तरफ नहीं। –

उत्तर

1

जैसा कि आपके प्रश्न पर टिप्पणियों में बताया गया है, फ़ाइल नामों को बदलने की कोई आवश्यकता नहीं है।

यह भी उल्लेख किया गया था कि यह आमतौर पर ऐसा नहीं होगा कि माइग्रेशन किसी अन्य माइग्रेशन के आधार पर लिखा जाता है, इससे पहले कि अन्य माइग्रेशन मौजूद हो। (यदि ऐसा होता है, तो आप सही काम नहीं कर रहे हैं)। तो जरूरत नहीं उठानी चाहिए।

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

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

+0

मुझे लगता है कि "आप सही काम नहीं कर रहे हैं" एक व्यापक व्यापक सामान्यीकरण है। हमारे पास अक्सर ऐसा मामला होता है जहां हम एक प्रवासन पर काम शुरू करते हैं, और फिर महसूस करते हैं कि एक अनिवार्य परिवर्तन है, इसलिए हमें इसे एक और उत्पन्न करना होगा और इसे पहले प्राप्त करना होगा। – lobati

+0

ऐसा नहीं होना चाहिए कि एक विशेषता शाखा देव शाखा में माइग्रेशन पर निर्भर है, जिस बिंदु पर वे अलग हो गए। ऐसा हो सकता है कि फीचर शाखा पर आप माइग्रेशन "प्रीपेन्ड" करना चाहते हैं - मैं सहमत हूं - लेकिन यह सवाल नहीं था। –

+0

मुझे यकीन नहीं है कि मैं समझ रहा हूं कि आप क्या कह रहे हैं। यहां एक उपयोग केस है: कई बार जब हम एक फीचर शाखा लिख ​​रहे हैं तो हमें एक माइग्रेशन की आवश्यकता होगी जो एक कॉलम जोड़ता है और इसे अन्य फ़ील्ड और टेबल से कुछ डेटा के साथ भर देता है। लेकिन इस प्रक्रिया में, हम महसूस करते हैं कि स्रोत डेटा किसी भी तरह से अमान्य है, इसलिए हम डेटा को साफ करने और कुछ बाधाओं को जोड़ने के लिए एक नई सुविधा शाखा बनाते हैं, विलय प्राप्त करते हैं, और फिर हमारी मूल सुविधा शाखा में वापस जाते हैं और काम जारी रखते हैं वहां से। क्या आप कह रहे हैं कि यह गलत है? – lobati

1

मुझे आपके लिए ऐसा करने के लिए रेल की सुविधा नहीं मिली है, लेकिन migration touch कमांड या कुछ होना अच्छा लगेगा। किसी भी दर पर, हम इन दिनों क्या करते हैं बस एक नया माइग्रेशन उत्पन्न करते हैं, टाइमस्टैम्प की प्रतिलिपि बनाते हैं और पुराने नाम का नाम बदलते हैं। आम तौर पर माइग्रेशन अकेले खड़े होते हैं कि ऑर्डर कोई फर्क नहीं पड़ता है, लेकिन कभी-कभी हम ऑर्डर निर्भरताओं में भाग लेते हैं, इसलिए हमें टाइमस्टैम्प अपडेट करना होगा।

+0

हेरेस एक [गीस्ट] (https://gist.github.com/craigweston/6e64f6677b281a3d7534fb8d30152341) है। यह नवीनतम संस्करण में फ़ाइल नाम अपडेट करता है, डीबी कॉल करता है: माइग्रेट: पुराने संस्करण और डीबी पर नीचे: माइग्रेट करें: नए संस्करण पर। – cweston

संबंधित मुद्दे