MSSQL से MySQL और BLToolkit की ओर जाते समय नुकसान

हमारे पास MSSQL 2008 है
हम MySQL संस्करण 5.x चाहते हैं

यह आवश्यक क्यों हो सकता है?

.NET डेवलपर्स के लिए, MySQL के लिए MSSQL का आदान-प्रदान संभवतः मर्सिडीज से कुछ आसान करने के लिए आगे बढ़ने के समान है। जैसा कि वे कहते हैं, आप जल्दी से अच्छे की आदत डाल लेते हैं।
लेकिन ऐसा करने के कम से कम दो कारण हैं।

• लाइसेंस पर सहेजें
• सरल मास्टर-दास प्रतिकृति प्राप्त करें

हमारे मामले में MSSQL बेस के साथ काम LINQ प्रदाता के माध्यम से किया जाता है।
संक्रमण होने पर, मैं इस अवसर को नहीं खोना चाहूंगा, इसलिए MySQL के साथ काम करने के लिए विकल्प BLToolkit पर गिर गया।

हम पलायन करते हैं

सबसे सरल बात कोड को फिर से लिखना है। MS प्रदाता के विपरीत, BLToolkit, प्रकाश ORM के वर्ग के अंतर्गत आता है, इसलिए थोड़ा अलग डेटाबेस कनेक्शन डिज़ाइन हैं, लेकिन LINQ अभिव्यक्तियाँ समान रहेंगी।

आपको लगता है कि यह डेटा स्थानांतरित करने के लिए बना हुआ है और यह सब काम करता है?
कोई फर्क नहीं पड़ता कि कैसे।

डेटा ट्रांसफर करें

माइग्रेशन के लिए, हमने MySQL माइग्रेशन टूलकिट का उपयोग किया।
अधिकांश प्रकार के MSSQL क्षेत्रों को समस्याओं के बिना निर्यात किया गया था, लेकिन प्रति कट दो क्षेत्रों को अस्वीकार कर दिया गया था:

• varchar
• datetime2

हमारे मामले में, स्रोत डेटाबेस में, हमने varchar को nvarchar, और datetime2 को datetime में बदल दिया। पहले के साथ, सब कुछ स्पष्ट है - फ़ील्ड ने केवल यूनिकोड में वर्णों को संग्रहीत करना शुरू किया, और दूसरे में हमारे पास कोई कारण नहीं था कि डेवलपर्स ने डेटाटाइम को 100 नैनोसेकंड की सटीकता के साथ संग्रहीत करने की आवश्यकता की, इस तथ्य को छोड़कर कि अगर हम डेटाइम डालते हैं। डेटाबेस में और फिर इसे निकालें, फिर गोलाई के कारण मान समान नहीं हो सकते हैं (इस तरह लिखा गया कुछ कार्यात्मक परीक्षण गिर गया और डेवलपर ने डेटटाइम 2 का उपयोग करके समस्या को हल किया)।

LINQ मैपिंग

एक प्रकार के टाइमस्टैम्प के एक क्षेत्र को उसी प्रकार के क्षेत्र में निर्यात किया जाता है, हालांकि इसका व्यवहार थोड़ा अलग है।
MSSQL के लिए .NET क्लास में, इसे कुछ अधूरे बायनरी टाइप द्वारा दर्शाया गया है, जिसके परिणामस्वरूप आपको LINQ के लिए इस तरह हैक करना होगा
MySQL में, यह एक नियमित डेटटाइम में अनुवाद करता है, लेकिन दो नुकसान हैं

1. निर्यात के बाद, आपको सभी टाइमस्टैम्प मूल्यों को शुरू करने की आवश्यकता है (उदाहरण के लिए, टाइमस्टैम्प क्षेत्र के लिए सेट सेट), क्योंकि निर्यात के बाद ठोस शून्य होगा जो BLToolkit को समझ में नहीं आता है
2. निर्धारित DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP सेट करें, अन्यथा फ़ील्ड स्वचालित रूप से अपडेट नहीं होगी, क्योंकि हम MSSQL में उपयोग किए जाते हैं। ( MySQL में टाइमस्टैम्प को अपडेट करने की विशेषताओं के बारे में पढ़ें)

इस स्तर पर, आपके पास पहले से ही एक परियोजना चल रही है और शायद कुछ भी काम कर रहा है।

यदि मानचित्रण इस तथ्य के कारण काम नहीं करता है कि वर्ग के कुछ क्षेत्रों के लिए तालिका में संबंधित फ़ील्ड नहीं पाए जाते हैं, तो यह संभव है क्योंकि MS LINQ के लिए आवश्यक वर्ग फ़ील्ड को [Column] विशेषता के साथ चिह्नित किया जाना चाहिए, और BLToolkit के लिए, इसके विपरीत, अतिरिक्त फ़ील्ड को विशेषता के साथ चिह्नित किया जाना चाहिए। [MapIgnore]

अगला अप्रिय आश्चर्य तथ्य यह हो सकता है कि BLToolkit फ़ील्ड नामों से बच नहीं जाता है, इसलिए आपको फ़ील्ड नाम के लिए अपनी तालिका में कुंजी जैसे किसी भी कीवर्ड का उपयोग नहीं करना चाहिए। LINQ अभिव्यक्ति का SQL क्वेरी में अनुवाद करते समय, यह एक सिंटैक्स त्रुटि के साथ क्रैश हो जाता है।

कार्यात्मक परीक्षण के लाभों के बारे में

यदि आपका कार्यक्रम परीक्षणों द्वारा कवर नहीं किया गया है, तो यह बहुत बुरा है।
केवल एक साधारण कार्यात्मक परीक्षण के लिए धन्यवाद, जिसने जाँच की कि डेटाबेस में NULL फ़ील्ड .NET .NET में एक अशक्त स्ट्रिंग के बराबर है, यह निकला कि BLToolkit defaults to string.Empty।
यह एक अप्रिय आश्चर्य होगा अगर कहीं खड़ा है if(value == null) ।

इस व्यवहार को बदलने के लिए आपको मैपिंग क्लास की एक विशेषता को पंजीकृत करना होगा
[NullValue(typeof(string), null)]

आखिरी खराबी जिसके बारे में मैं बात कर सकता हूं वह है एक गाइड टाइप फील्ड मैपिंग।
जैसा कि आप MySQL में जानते हैं कि गाइडिंग स्टोर करने के लिए कोई विशेष प्रकार नहीं है।
इसके लिए, वहाँ चार (36) का उपयोग किया जाता है।
प्रदर्शित होने पर Guid.Parse फ़ंक्शन का उपयोग करता है।
उदाहरण के लिए, इस तरह के कोड का उपयोग दिशानिर्देश में चार (36) फ़ील्ड प्रदर्शित करने के लिए किया जाना चाहिए

 [TableName("Boxes")] public class Box: { [PrimaryKey] public Guid BoxId { get; set; } } 

जब तक कोई व्यक्ति तालिका में मार्गदर्शिका के अलावा कुछ डालने की कोशिश करता है तब तक सब कुछ बहुत अच्छा लगता है।
और भले ही मैपिंग क्लास में आप इस फील्ड को string रूप में परिभाषित करते हैं, लेकिन BLToolkit अभी भी Guide.Parse बनाने की कोशिश करेगी
उदाहरण के लिए, ऐसा कोड क्रैश हो जाएगा जब StringMayContainsGuid को चार (36) से पढ़ने की कोशिश कर रहा है, जो एक गाइड नहीं है।

 [TableName("Boxes")] public class Box: { public string StringMayContainsGuid { get; set; } } 

इस मामले में एक सरल समाधान फ़ील्ड प्रकार को varchar में बदलना है।

इस तरह की समस्याओं को खोजने के लिए एक उपकरण के रूप में, मैंने एक सरल कार्यात्मक परीक्षण लिखा है जो तालिकाओं के सभी डेटा को पढ़ता है:

 [TestFixture, Category("Functional")] public class DbFunctionalTest { private readonly IMysqlClient mysqlClient = new MysqlClient(); //        [Test] public void ReadAllTables() { var dbMappingClasses = from classType in Assembly.GetExecutingAssembly().GetTypes() where classType.IsClass && classType.GetCustomAttributes(typeof(TableNameAttribute), true).Length > 0 && classType.Namespace == typeof(DbFunctionalTest).Namespace select classType; mysqlClient.PerformRequest(db => { foreach (Type dbMappingClass in dbMappingClasses) { var tableName = ((TableNameAttribute) dbMappingClass.GetCustomAttributes(typeof (TableNameAttribute), true).First()).Name; try { db.SetCommand(CommandType.Text, string.Format("SELECT * FROM {0}", tableName)).ExecuteList(dbMappingClass); }catch(Exception e) { throw new Exception(string.Format("Can not read all records from table {0}", tableName), e); } } }); } } 

निष्कर्ष में

मुझे उम्मीद है कि वर्णित अनुभव किसी के लिए उपयोगी होगा।
लेकिन वास्तव में, मेरी कपटी योजना को आपकी टिप्पणियों से और भी अधिक लाभ मिलना था, इसलिए आपका स्वागत है!