क्या यह एक अच्छा विचार है कि db/schema.rb को .gitignore सूची में डालें ??

Question

तो मैं अपने काम में जो सुझाव दे रहा हूं, वह dg/schema.rb को .gitignore फ़ाइल में डालना है, इसलिए हमारे पास विलय समस्याएं नहीं हैं (समय-समय पर)।

कुछ चिंताएं हैं कि अगर कुछ भयानक होता है (डीबी सर्वर पर आकाश से उल्का गिरता है और साथ ही सभी डीबी/माइग्रेट फाइल भ्रष्ट हैं) हम स्कीमा को खो सकते हैं, और हमें रेक डीबी का उपयोग करना होगा: purge (schema.rb का पुन: उपयोग करने के लिए)। मैं मानता हूं कि यह संभव है और यह एक अच्छा तर्क है, लेकिन यह समस्या नहीं होनी चाहिए क्योंकि हर बार जब हम रेक डीबी करते हैं तो डीबी/schema.rb उत्पन्न होता है: माइग्रेट करें। तो अगर हम सर्वर पर schema.rb को नहीं दबाएंगे, तो हम माइग्रेशन को चल रहे हैं डीबी चलाना जोड़ते हैं: प्रत्येक बार जब हम डीबी परिवर्तनों के साथ तैनात होते हैं तो माइग्रेट करते हैं और उस डीबी के साथ: माइग्रेट रेल स्वचालित रूप से सर्वर पक्ष पर schema.rb उत्पन्न करेंगे, और वह schema.rb सर्वर पर अपरिवर्तित है जब तक हम एक और डीबी नहीं करते: माइग्रेट करें।

तो आपकी राय क्या है, क्या हमें डीबी/schema.rb को गिट अनदेखा में नहीं रखना चाहिए?

धन्यवाद

Answer 1

मैं हमेशा संस्करण contol में schema.rb रखने का सुझाव देता हूं, क्योंकि रेक डीबी जैसे कार्य: स्कीमा: लोड उस पर निर्भर करता है।

विवादों के बारे में, क्या आप स्कीमा संस्करण विवादों के बारे में बात कर रहे हैं? इन्हें यहां दिखाए गए मर्ज एल्गोरिदम का उपयोग करके आसानी से कम किया जाता है: http://tbaggery.com/2010/10/24/reduce-your-rails-schema-conflicts.html

कॉलम परिभाषा स्विचिंग स्थानों जैसे अन्य विवादों को सावधानी बरतने से बचा जा सकता है जो आप रिपोजिटरी को प्रतिबद्ध करते हैं।

Answer 2

आप एक VCS जो कुछ भी आप एक संचालन पर्यावरण पुन: पेश करने की जरूरत है में डाल दिया जाना चाहिए।
यदि, अपने आवेदन के पुनर्निर्माण के लिए, आपको सही schema.rb (दाएं संस्करण पर) होना चाहिए, तो हाँ, इसे संस्करणित किया जा सकता है।

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

Answer 3

आप सुविधा शाखाओं जो मॉडल विशेषताओं के विभिन्न सेट विकसित के बीच स्विच करते हैं, तो schema.rb बिना आप कभी कभी की आवश्यकता होगी:

1. rake db:migrate:down VERSION=xxx माइग्रेशन थे जो कुछ समय पहले बनाने के लिए, लेकिन अन्य शाखाओं के लिए विलय नहीं
2. git checkout branch
3. rake db:migrate विस्थापित सभी नव निर्मित शाखाओं

मैं som में चलाने पिछली परियोजनाओं में इस के साथ समस्याएं जहां schema.rb .gitignore में था। जब भी मुझे कुछ गलत लगता था, मुझे डेटाबेस छोड़ना पड़ता था और माइग्रेशन से फिर से बनाना था, जबकि schema.rb के साथ मैं डेटा लोड करने के लिए दूसरे के अंश में स्कीमा लोड कर सकता था और फिर rake db:seed लोड कर सकता था। लेकिन यह महत्वपूर्ण नहीं था।

मैं भी उत्सुक हूं कि schema.rb विलय के साथ आपके पास क्या समस्याएं हैं? अधिकतर समय आप परिवर्तनों के बारे में चिंता किए बिना इस फ़ाइल को ओवरराइड कर सकते हैं (मुझे लगता है कि आपने हाथ से अपनी डेटाबेस संरचना को संशोधित नहीं किया है) rake db:dump के साथ और इसे मर्ज रिज़ॉल्यूशन के रूप में जोड़ें।