2009-12-11 4 views
5

तोड़ने के बिना ओरेकल पैकेजों के प्रबंधन के लिए रणनीति मैं यह जानकर उत्सुक हूं कि लोग अपने अनुप्रयोगों में अपने पैकेज कैसे प्रबंधित करते हैं।कोड

उदाहरण के लिए, हमारे विकास उदाहरण में, एक एप्लिकेशन डेवलपर एक संग्रहीत प्रक्रिया में बदलाव चाहता है। हालांकि, संग्रहित प्रक्रिया को बदलने से मौजूदा जावा कोड तोड़ दिया जाएगा जब तक कि परिवर्तनों के लिए समायोजित करने के लिए डीएओ परत अद्यतन नहीं किया जाता है।

मेरा सामान्य अभ्यास नई प्रक्रिया कार्यान्वयन को "DEV" पैकेज में रखना है। डेवलपर उसके बाद इस पैकेज में अपना संदर्भ बदल सकता है, उसका परीक्षण कर सकता है और फिर जब हम तैयार होते हैं, तो हम प्रक्रिया को "उत्पादन" पैकेज में बदल सकते हैं, इसे DEV से हटा सकते हैं और डेवलपर उत्पादन संदर्भ में अपना संदर्भ बदल सकता है।

हालांकि, मुझे लगता है कि यह तैराकी के रूप में काम नहीं करता है जैसा मैं चाहूंगा। सबसे पहले, यदि जावा कोड का एक गुच्छा है जो DEV पैकेज पर निर्भर करता है, तो मैं उसी स्थिति में हूं जैसे कि उत्पादन पैकेज को सीधे संपादित कर रहा था - अगर मैं पैकेज तोड़ता हूं, तो मैं कोड का एक गुच्छा तोड़ दूंगा।

दूसरा, लोग व्यस्त हो जाते हैं और हम पैकेज को जल्द से जल्द उत्पादन में स्थानांतरित करने के लिए नहीं जाते हैं। फिर हमारे पास संग्रहीत प्रक्रिया के दो संस्करण हैं जो आसपास तैरते हैं और यह याद रखना मुश्किल हो जाता है कि उत्पादन में क्या स्थानांतरित हो गया है और क्या नहीं है।

लक्ष्य डेवलपर्स को काम करना है। हां, यह एक विकास सर्वर है, लेकिन हम अप्रत्याशित रूप से कोड तोड़ना नहीं चाहते हैं।

क्या कोई इस समस्या को हल करने के लिए उनके लिए काम करने वाली पद्धतियों का सुझाव दे सकता है?

उत्तर

3

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

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

1

प्रक्रिया विनिर्देश परिवर्तन (यानी पैरामीटर के नाम, नाम इत्यादि) में जावा/डीएओ परत केवल तभी प्रभावित होनी चाहिए। इसके लिए मिटाने की रणनीतियों

  1. पैरामीटर के लिए DEFAULT मानों के साथ नए पैरामीटर जोड़ें ताकि उन्हें पारित करने की आवश्यकता न हो।
  2. पैरामीटर के क्रम को न बदलें अगर उन्हें स्थितित्मक रूप से कॉल किया जाता है [जैसे pkg.proc_a (1,2,3)], या नाम से बुलाए जाने पर उनका नाम बदलें [जैसे pkg।proc_b (p_1 => 1, p_2 => 2)] प्रक्रियाओं और कार्यों के लिए
  3. संकुल का उपयोग करें ताकि आप को ओवरलोड कर सकते हैं उन्हें

    बनाने या बदलने के लिए pkg proc (varchar2 में p1) है; proc (varchar2 में p1, संख्या में पी 2); अंत;

अधिक भार तुम सिर्फ अलग अलग संख्या और/या मापदंडों

11gR2 Editioning शुरू की है इस समस्या को हल करने के लिए की डेटाटाइप्स के साथ एक पैकेज में एक ही नाम के साथ कई प्रक्रियाओं हो सकता है के साथ

। यह संकुल के कई संस्करणों को अनुमति देता है और एप्लिकेशन कोड उस कोड का 'संस्करण' (संस्करण) चुनता है जिसे वह देखना चाहता है - डिफ़ॉल्ट 'आधार' संस्करण या विकास संस्करण।

हालांकि मुझे संदेह है कि डेटाबेस संस्करण को अपग्रेड करना एक व्यावहारिक समाधान नहीं है।