2012-11-27 40 views
6

मेरे पास एक ही डेटाबेस साझा करने वाला एक रेल ऐप और एक सिनात्रा ऐप है। सिनात्रा ऐप ActiveRecord का उपयोग करता है।माइग्रेशन प्रबंधित करने के लिए कैसे करें जब एकाधिक ऐप्स रूबी में समान डेटाबेस साझा करते हैं?

क्या मैं प्रत्येक ऐप के भीतर से माइग्रेशन चला सकता हूं, जैसे कि वे एक ही ऐप में थे? क्या इससे कोई समस्या होगी?

रेल अनुप्रयोग में schema.rb फ़ाइल

ActiveRecord::Schema.define(:version => 20121108154656) do 

लेकिन के माध्यम से वर्तमान माइग्रेशन ट्रैक करता है, कैसे सिनात्रा एप्लिकेशन वर्तमान संस्करण डेटाबेस में पता है?

रेल 3.2.2, रूबी 1.9.3।

उत्तर

0

मैं रेल अनुप्रयोग में सभी माइग्रेशन लगाने का फैसला किया है क्योंकि:

  1. वहाँ केवल एक ही डेटाबेस
  2. रेल माइग्रेशन

यह अच्छी तरह से काम किया है का प्रबंधन करता है के बाद से।

यह सिस्टम को सरल बनाता है क्योंकि सभी माइग्रेशन एक ही स्थान पर संग्रहीत होते हैं। और, सिनात्रा ऐप को उनके बारे में जानने की आवश्यकता नहीं है।

+0

मेरे उत्तर में क्या गलत था? आपने उल्लेख किए गए दूसरे विकल्प विकल्प में से एक चुना है ... – Schmurfy

+0

केवल एक डेटाबेस है। –

3

आप एक ही डेटाबेस के लिए दोनों अनुप्रयोगों कनेक्ट यदि आप उस पर माइग्रेशन चलाने में सक्षम होना चाहिए, लेकिन मैं दृढ़ता से जब से तुम लगभग निश्चित रूप से एक समय या किसी अन्य पर एक दीवार से टकरा होगा यदि आप किसी अन्य विकल्प का उपयोग करने का सुझाव:

  • अपने डेटाबेस/माइग्रेशन के लिए जिम्मेदार प्रत्येक एप्लिकेशन के साथ यदि संभव हो तो डेटाबेस को दो में विभाजित करें।

  • एक आवेदन "मास्टर" डेटाबेस माना जाता है और दूसरे अनुप्रयोग के लिए विशिष्ट डेटा के लिए एक और डेटाबेस का उपयोग लेकिन (प्रत्येक आवेदन अभी भी केवल एक ही डेटाबेस के लिए माइग्रेशन लागू)

यह दोनों डेटाबेस से कनेक्ट होता है बनाने के लिए है

यदि आपको एकाधिक अनुप्रयोगों के बीच डेटा साझा करने की आवश्यकता है तो दूसरा विकल्प एक में एक आरईएसटी सेवा को लागू करना है और इसे दूसरे पर उपयोग करना है, तो आप ऐसा करने के एक सरल तरीके के लिए अंगूर मणि को देख सकते हैं।

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

+0

+1। – harald

+0

मुझे नहीं लगता कि इनमें से कोई भी समाधान काम करेगा क्योंकि उन्हें दोनों को एक ही डेटा साझा करने की आवश्यकता है, और मुझे लगता है कि एक डेटाबेस चलाने के लिए यह आसान है ... लेकिन शायद मैं रेल माइप में सभी माइग्रेशन डाल सकता हूं ... –

+0

मैंने एक्टिव्रेकॉर्ड माइग्रेशन कैसे काम करते हैं, इस बारे में एक स्पष्टीकरण जोड़ा कि दोनों एप्लिकेशन कितने स्वतंत्र हैं? यदि आप एक ही समय में दोनों को वितरित/स्थापित/तैनात कर सकते हैं तो आप यह तय कर सकते हैं कि उनमें से एक माइग्रेशन के लिए ज़िम्मेदार है और यहां तक ​​कि उन्हें दोनों को एक ही गिट/svn/.... दोनों में भी चलाया जा सकता है .... – Schmurfy

1

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

यदि आपका मामला सरल है तो आप दोनों ऐप्स से केवल एक डेटाबेस का उपयोग कर सकते हैं, और चूंकि आप दोनों में एआर का उपयोग करते हैं, आपको संस्करण के साथ कोई समस्या नहीं है, एआर इसका ख्याल रखता है।

इसके अलावा मुझे नहीं पता है अगर आप db चलाने क्या होता है

: दोनों क्षुधा simultaniously से माइग्रेट अगर आप mysql जो लेन-देन, निश्चित रूप से अच्छा कुछ भी नहीं में DDL की अनुमति नहीं है की तरह एक अवर डीबीएमएस का उपयोग ..

यह भी परेशान करेगा मुझे यह देखने के लिए कि कौन से ऐप को कॉलम चाहिए और एक स्थान पर माइग्रेशन नहीं है। आप दोनों ऐप्स से माइग्रेशन प्रबंधित करने के लिए एक साझा भंडार का उपयोग कर सकते हैं।

+0

मैं नहीं दौड़ूंगा माइग्रेशन एक साथ ... –

+0

मैं बस एक स्पष्ट रूप से स्पष्ट pitfall को इंगित करना चाहता था। – Andreas

1

रेल माइग्रेशन डेटाबेस में schema_migrations तालिका में वर्तमान डेटाबेस संस्करण को स्टोर करता है। तो आपके दोनों ऐप्स वर्तमान संस्करण की जांच करने में सक्षम होंगे।

संस्करण संख्या टाइमस्टैम्प हैं, इसलिए डुप्लिकेट मानों के साथ कोई समस्या नहीं होनी चाहिए, क्योंकि सटीक उसी मिलीसेकंड पर दो माइग्रेशन उत्पन्न करना लगभग असंभव होगा। तो आपको यहाँ ठीक होना चाहिए।

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

4

schema_migrations तालिका में संस्करण कॉलम रूबी माइग्रेशन फ़ाइल उदाहरण के सामने टाइम स्टैंप के बराबर है: 20130322151805_create_customers.rb तो यदि दो अयस्क अधिक अनुप्रयोग schema_migrations तालिका में योगदान दे रहे हैं तो रोल बैक संभव नहीं होंगे यदि रेल नीचे() विधि नहीं ढूंढें (क्योंकि इसे किसी अन्य ऐप यानी डीबी/माइग्रेट/...)

में एक माइग्रेशन फ़ाइल नहीं मिलेगी, मेरे पास वर्तमान स्थिति है जो वास्तव में है और मैंने इसे चुना है मास्टर ActiveRecord ऐप जो माइग्रेशन और डेटा रूपांतरण प्रबंधित करता है क्योंकि हमारे डेटाबेस विकसित होते हैं। ध्यान रखें कि सौदा का हिस्सा मॉडलों को अद्यतित रखना है। यह समय लेने वाला रहा है इसलिए हम किसी अन्य एप्लिकेशन के लिए समर्थन डेटा पूछने के लिए व्यापार डोमेन में डीबी को अलग करने और एपीआई (जेएसओएन) प्रदान करने पर विचार कर रहे हैं। इस तरह प्रत्येक एप्लिकेशन इसे डोमेन प्रबंधित करता है और एपीआई के माध्यम से डेटा को उजागर करने के लिए ज़िम्मेदार है।

संबंध। एक REST एपीआई सुझाव देने के लिए