मैं अन्य ORM के पर टिप्पणी नहीं कर सकता, लेकिन मैं 2007 से कॉर्पोरेट ट्रेजरी एप्लिकेशन के लिए DevExpress XPO का उपयोग किया है। स्कीमा प्रत्येक रिलीज के साथ थोड़ा बदलता है लेकिन वर्षों में भी कुछ बड़े स्कीमा परिवर्तन हुए हैं। डिफ़ॉल्ट XPO अपग्रेड तंत्र का कुछ हद तक विस्तारित संस्करण सभी परिवर्तनों के लिए आराम से catered है।
XPO अनुप्रयोगों को अपग्रेड करने के बारे में अच्छी बुनियादी जानकारी here है।
देवएक्सप्रेस उत्पादन वातावरण को अपग्रेड करने के कार्य के साथ आपकी सहायता के लिए एक डीबी अपडेटर टूल प्रदान करता है। आप अतिरिक्त आवश्यकताओं को पूरा करने के लिए इस टूल का विस्तार कर सकते हैं। मेरे आवेदन में, हमने लॉगिंग, रोलबैक के साथ पूर्वावलोकन, आदि के लिए कुछ विकल्प जोड़े हैं
प्रत्येक मॉड्यूल में वर्चुअल UpdateDatabaseBeforeSchemaUpdate() और UpdateDatabaseAfterSchemaUpdate() विधियां हैं। आप इनके भीतर अपग्रेड प्रक्रिया को महत्वपूर्ण रूप से नियंत्रित कर सकते हैं।
तुम उल्लेख के रूप में, उन्नयन के कुछ XPO द्वारा स्वचालित रूप से नियंत्रित किया जाएगा (जैसे, एक नया स्तंभ जोड़ने), लेकिन कुछ चीजें ऐसी मौजूदा रिकॉर्ड के लिए एक डिफ़ॉल्ट मान के साथ नया स्तंभ initialising के रूप में अतिरिक्त नियंत्रण की जरूरत है।
उदाहरण के लिए, मान लें कि MyNewField को आपके आवेदन के संस्करण 2.0 में MyEntity XPO कक्षा में जोड़ा गया है। मान लें कि मौजूदा रिकॉर्ड के लिए इसे 3 के मान पर डिफ़ॉल्ट होना चाहिए। एक्सपीओ नए कॉलम के निर्माण को संभालेगा लेकिन मौजूदा रिकॉर्ड शून्य होंगे। (यदि आप XPO कक्षा में डिफ़ॉल्ट मान निर्दिष्ट करते हैं तो यह केवल नए रिकॉर्ड से संबंधित होगा)। आदेश मौजूदा रिकॉर्ड के लिए मान को ठीक करने के लिए आपको इकाई मॉड्यूल के ओवरराइड UpdateDatabaseAfterSchemaUpdate() के लिए निम्न की तरह कुछ जोड़ना होगा: (। तुम भी ObjectSpace.GetObjects<MyEntity>() का उपयोग करें और एक foreach सकता है अगर आप सीधे एसक्यूएल से बचने के लिए पसंद करते हैं)
public override void UpdateDatabaseAfterUpdateSchema()
{
base.UpdateDatabaseAfterUpdateSchema();
if (CurrentDBVersion < new Version(2, 0, 0, 0))
ObjectSpace.GetSession().ExecuteNonQuery(
"UPDATE [MyEntity] SET [MyNewField] = 3 WHERE [MyNewField] IS NULL");
}
दो में एक तालिका को विभाजित करने के आपके अत्यधिक चरम उदाहरण में, आप एक ही विधि का उपयोग कर सकते हैं, लेकिन आप UpdateDatabaseBeforeUpdateSchema() को ओवरराइड करेंगे, एसक्यूएल को तालिका को विभाजित करने के लिए चलाएं, XPO को किसी भी अन्य स्कीमा अपडेट करने दें और यदि आवश्यक हो, तो किसी भी को पॉप्युलेट करें UpdateDatabaseAfterUpdateSchema() में डिफ़ॉल्ट मान।
आप पाएंगे कि आप उदाहरण के लिए, विदेशी कुंजी उल्लंघन बाधा समस्याओं में टक्कर ताकि आप पा सकते हैं आप UpdateDatabaseBeforeUpdateSchema() के हिस्से के रूप में इस तरह के DropAllForeignKeyConstraints() के रूप में कुछ सामान्य दिनचर्या लिखने की ज़रूरत मिल जाएगा। कभी-कभी आप पाते हैं कि XPO पहले से ही कुछ प्रदान करता है, कभी-कभी नहीं। स्कीमा अपडेट में लापता बाधाएं और इंडेक्स पुन: उत्पन्न हो जाएंगे। (मेरे अनुभव में एक मास्टर डेटा टेबल की प्राथमिक कुंजी को सही करने के लिए सबसे कठिन अद्यतन दिनचर्या को बदल दिया गया।)
डिफ़ॉल्ट रूप से सभी कॉल एसक्यूएल लेनदेन में होते हैं, इसलिए अगर कुछ विफल हो जाता है तो इसे वापस रोल करना चाहिए।
डेवलपर्स को इस बात से अवगत होना चाहिए कि डोमेन मॉडल में परिवर्तन के दौरान अंतर्निहित स्कीमा के साथ समस्या हो सकती है।
परीक्षण के लिए, हम कुछ पुराने ग्राहक डेटाबेस रखते हैं और बिल्ड प्रक्रिया के हिस्से के रूप में परीक्षण के पहले और बाद में परीक्षण का एक गुच्छा चलाते हैं ताकि यह सुनिश्चित किया जा सके कि मौजूदा ग्राहक जो भी संस्करण अपग्रेड कर रहे हैं, ठीक से अपग्रेड कर सकें। उत्पादन में जब भी हम किसी समस्या को अपग्रेड करते हैं, तो भविष्य में समान समस्याओं को रोकने के लिए समस्या डेटा को इस परीक्षण पुस्तकालय में जोड़ा जाता है।
हम प्रमुख अंतरराष्ट्रीय कंपनियों और बैंकों से निपट रहे हैं। परिणाम परिणाम से काफी खुश हैं। ऐसी परिस्थितियों में जहां कॉर्पोरेट के डीबीए को परिवर्तनों पर हस्ताक्षर करने की आवश्यकता होती है, उन्हें लगता है कि स्क्रिप्ट के बजाय अपग्रेड करने के लिए कमांड लाइन उपकरण नहीं है।
आपने जो वर्णन किया है वह एक्सएएफ से संबंधित है, न कि एक्सपीओ विशेष रूप से। – Yuyo