बहु-डेवलपर वातावरण में डेटाबेस दृश्यों का माइग्रेशन प्रबंधित करना

Question

क्या कोई स्थापित प्रथा है कि बहु-डेवलपर/बहु-शाखा (वीसीएस) वातावरण में डेटाबेस दृश्यों का माइग्रेशन सफलतापूर्वक कैसे प्रबंधित किया जा सकता है?

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

प्रत्येक डेवलपर की डेटाबेस की अपनी प्रति है, लेकिन विचारों के रूप में आमतौर पर माइग्रेशन में निर्दिष्ट होने वाली पूरी परिभाषा की आवश्यकता होती है, इसका मतलब है कि जब हम स्टेजिंग या उत्पादन डेटाबेस के खिलाफ माइग्रेशन चलाने के लिए आते हैं, जो भी माइग्रेशन देखता है आखिरी बार किसी भी पिछले दृश्य माइग्रेशन में किए गए किसी भी बदलाव को ओवरराइट करता है।

उदाहरण: SELECT 'x':

1. देखें वर्तमान की तरह दिखता है।
2. डेवलपर 1 शाखा ए शुरू करता है और एक नया कॉलम जोड़ता है। उनका 'अप' माइग्रेशन इस तरह दिखता है: SELECT 'x', 'y'।
3. डेवलपर 2 शाखा बी शुरू करता है और एक नया कॉलम जोड़ता है। उनका 'अप' माइग्रेशन इस तरह दिखता है: SELECT 'x', 'z'।
4. डेवलपर 2 अपनी शाखा को पहले खत्म करता है और माइग्रेशन चलाता है। दृश्य अब SELECT 'x', 'z' जैसा दिखता है।
5. डेवलपर 1 अब अपनी शाखा समाप्त करता है और माइग्रेशन चलाता है। दृश्य अब SELECT 'x', 'y' जैसा दिखता है और डेवलपर 2 के परिवर्तन खो गए हैं।

Answer 1

यदि वे अलग-अलग कोड शाखाओं में काम कर रहे हैं, तो वे अलग-अलग डेटाबेस का उपयोग कर रहे हैं; और जब शाखाएं विलय हो जाती हैं तो मतभेदों का समाधान किया जाना चाहिए।

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

मेरा उत्तर है (यदि यह विकास में बहुत देर हो चुकी है) मानक क्लाइंट कोड एक MySQL उपयोगकर्ता के अंतर्गत कनेक्ट है जिसके पास आवश्यकतानुसार डेटाबेस को बदलने की अनुमति नहीं है; और एक "माइग्रेशन" एप्लिकेशन/स्क्रिप्ट/जो कुछ भी उपयोगकर्ता खाते के अंतर्गत कनेक्शन के साथ चलता है, तालिकाओं, विचारों, प्रक्रियाओं इत्यादि को बदलने के लिए आवश्यक अनुमतियों के साथ ...

Answer 2

विचारों के लिए, या किसी डेटाबेस डेटाबेस जो हो सकता है किसी भी समय (जैसे फ़ंक्शंस) को फिर से परिभाषित किया गया है, मैंने पाया है कि सबसे अच्छा अभ्यास फ़ंक्शन की वर्तमान परिभाषा को अपनी फ़ाइल में संग्रहीत करना है, उदाहरण के लिए, db/views/your_stuff.view.sql; फिर, जब भी कोई डेवलपर उस दृश्य को बदलना चाहता है, तो वे उस फ़ाइल को बदलते हैं, फिर बॉयलरप्लेट माइग्रेशन जोड़ें जो नवीनतम संस्करण से दृश्य को फिर से परिभाषित करता है (मुझे नहीं पता कि आप रेल में हैं या नहीं, लेकिन यहां विचार होना चाहिए बहुत स्पष्ट होना):

class UpdateYourStuffView < ActiveRecord::Migration 
    def up 
    execute File.read("#{Rails.root}/db/views/your_stuff.view.sql") 
    end 

    def down 
    # You could expand this to actually track older versions, 
    # but that's generally not worth it. 
    raise ActiveRecord::IrreversibleMigration 
    end 
end 

ध्यान दें कि वास्तविक दृश्य फ़ाइल दिखना चाहिए: क्योंकि कार्यप्रवाह अब है

CREATE OR REPLACE VIEW your_stuff AS (SELECT 'x' FROM foos); 

यह आपकी समस्या नहीं सुलझती,:

1. देखें वर्तमान की तरह दिखता है : SELECT 'x' FROM foos।
2. डेवलपर 1 शाखा ए शुरू करता है और एक नया कॉलम जोड़ता है। इस परिवर्तन को दर्शाने के लिए वे db/views/your_stuff.view.sql संशोधित करते हैं; उनका प्रवासन केवल नए दृश्य को चलाता है।
3. डेवलपर 2 शाखा बी शुरू करता है और एक नया कॉलम जोड़ता है। वे एक ही फाइल को संशोधित करते हैं, और ऊपर जैसा ही एक नया माइग्रेशन जोड़ते हैं।
4. डेवलपर 2 अपनी शाखा को पहले खत्म करता है और माइग्रेशन चलाता है। दृश्य अब SELECT 'x', 'z' जैसा दिखता है।
5. डेवलपर 1 अब अपनी शाखा समाप्त करता है। हालांकि, मास्टर में विलय करने के लिए, उसे दृश्य फ़ाइल में संघर्ष को हल करना होगा। एक बार वह करता है, और माइग्रेशन चलाता है, दृश्य में अब सभी तीन कॉलम शामिल हैं।