Canasta और Senorit, भाग 3 के साथ Android के लिए अपना ओआरएम लिखना

प्रविष्टि

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

परिवर्तन और परिवर्धन

पहली बात जो मुझे सामने आई वह थी कंटेंटप्रोविडर और कर्सर की आवश्यकता।
कन्टैंटप्रॉइडर के साथ कोई विशेष समस्या नहीं थी - कंटेंटप्रोवाइडर से अमूर्त ऑरमकंटेंटप्रोइडर विरासत में मिलता है और अब तक दो तरीकों को लागू करता है: क्वेरी , जो ऑरमवेर को स्वीकार करता है और ऑरमस्कोरर को लौटाता है, और अपडेट करता है, जो अपडेटेड इंस्टेंस को स्वीकार करता है। OrmCursor को AbstractCursor से विरासत में मिला है और सभी आवश्यक तरीकों को लागू करने के अलावा, यह getEntities विधि को भी लागू करता है - जो वस्तुओं की एक सूची देता है। कार्यान्वयन के दृष्टिकोण से सबसे दिलचस्प, getColumnNames फ़ंक्शन है, जो कॉलम नामों की एक सरणी देता है ( getOrmFields फ़ंक्शन पहले से ही फिर से तैयार हो चुका है), और निजी getObject फ़ंक्शन, जो निर्दिष्ट स्तंभ का मान लौटाता है। इन वर्गों ने एक सिंक्रनाइज़ेशन खाते के विकास को बहुत सरल किया है।
दूसरा नवाचार नए क्षेत्र प्रकारों के लिए समर्थन था: बूलियन और इंट सरणी । यदि बूलियन के साथ सब कुछ कम या ज्यादा स्पष्ट है, तो मैं आपको सरणी के बारे में थोड़ा और बताऊंगा। सबसे पहले, विचार " class_name field_name " नाम के साथ एक अतिरिक्त तालिका बनाने के लिए आया और सरणी के घटक के प्रकार का एक एकल स्तंभ। हालाँकि, तर्क के अनुसार, मैं इस नतीजे पर पहुंचा कि ऑरमइंटिटी से विरासत में मिली क्लास के साथ एक सरणी पूरी वास्तुकला को नष्ट कर देती है, और डेवलपर को किसी अन्य गैर-आदिम प्रकार को मैन्युअल रूप से क्रमबद्ध करना होगा। यहाँ से मैंने तय किया कि orm केवल आदिम प्रकार के सरणियों का समर्थन करेगा जो पूरी तरह से एक स्ट्रिंग को क्रमबद्ध करते हैं और साथ ही पूरी तरह से पीछे हटते हैं। समस्याएं, शायद, एक डबल के साथ उत्पन्न हो सकती हैं, जिनमें से एक स्ट्रिंग के रूप में प्रारूप में अल्पविराम हो सकता है, जो कि सरणी के तत्वों का विभाजक है, लेकिन वे आसानी से अंग्रेजी में लोकेल को सेट करके आसानी से हल कर सकते हैं।
इसके अलावा, मैं अंततः OrmHelper के वारिस में getDefaultValues विधि के कार्यान्वयन के लिए मिला । अब यह इस तरह दिखता है:

@Override public void getDefaultValues(Class<? extends OrmEntity> entityClass, List<OrmEntity> valueList) { } 

तदनुसार, दूसरे भाग से हमारे पसंदीदा मॉडल के लिए डिफ़ॉल्ट मान जोड़ना निम्नानुसार लागू किया जाएगा:

  public void getDefaultValues(Class<? extends OrmEntity> entityClass, List<OrmEntity> valueList) { if (entityClass.equals(CarType.class)) { valueList.add(new CarType("Passenger")); valueList.add(new CarType("Truck")); } } 

खैर, अब हमें सबसे स्वादिष्ट समस्या मिली कि हार्डेक्स ने पहले लेख में बात की - डेटा स्कीमा को अपडेट करना।

डेटा स्कीमा अपडेट

फिर से, हमारे मॉडल पर वापस जाएं और कार के सार पर विचार करें:

  @Table(rightJoinTo = {Truck.class}) public class Car extends BaseEntity { @Column(name = "car_type") private CarType type; @Column private List<Wheel> wheels; @Column(name = "engine_power") private int enginePower; @Column(name = "doors_count") private int doorsCount; } 

मान लीजिए कि हम एक और क्षेत्र जोड़ने का फैसला करते हैं:

  @Column(name = "max_speed") private int maxSpeed; 

इस मामले में, हमें डेटाबेस के संस्करण को प्रकट में बदलने की आवश्यकता है:

 <meta-data android:name="UO_DB_VERSION" android:value="2" /> 

और onUpdate सहायक विधि में कोड लिखें:

  @Override protected void onUpgrade(int oldVersion, int newVersion) { if (newVersion == 2) { OrmUtils.UpdateTable(Car.class).work(); } } 

“ हमें कार्य विधि की आवश्यकता क्यों है? ”- कोई पूछेगा। और डेटा योजना को बदलने के संभावित विकल्पों पर नज़र डालते हैं:

1. स्कीमा में एक नया फ़ील्ड जोड़ा जाता है।
2. फ़ील्ड स्कीमा से हटा दिया गया है।
3. क्षेत्र का नाम बदला गया है।
4. क्षेत्र का प्रकार बदल रहा है।

सबसे अधिक संभावना है, कई लोग पहले ही अनुमान लगा चुके हैं कि केवल एक ही बिंदु जो कठिनाइयों का कारण नहीं है, लेकिन हम उन्हें क्रम में विचार करेंगे।

क्षेत्र जोड़

यहां सब कुछ आसान है: ओआरएम टेबल से खेतों को पकड़ते हैं और उनकी तुलना क्लास से खेतों से करते हैं। जब एक नया क्षेत्र ऑब्जेक्ट मॉडल में होता है, तो यह जुड़वा हो जाता है

 ALTER TABLE … ADD COLUMN … 

यदि कोई डिफ़ॉल्ट मान आवश्यक है, तो उसे एनोटेशन में इंगित करना होगा।

क्षेत्र विलोपन

एल्गोरिथ्म की शुरुआत पिछले एक के समान है: हम खेतों की तुलना करते हैं और उन लोगों को ढूंढते हैं जिन्हें हटाने की आवश्यकता है। खैर, फिर, लगभग, जैसा कि faq में संकेत दिया गया है। केवल एक चीज जो मुझे समझ में नहीं आती है कि दूसरी प्रति की आवश्यकता क्यों है, क्योंकि तालिका के शून्य ' ड्रॉप ' के बाद, आप बस अस्थायी नाम बदल सकते हैं और यह स्थायी हो जाएगा!

फ़ील्ड का नाम बदलें

और यहाँ काम आपका सहायक नहीं है! ऑरम बस यह नहीं समझेंगे कि आपने केवल फ़ील्ड का नाम बदला है, और दो काम करेंगे: डेटाबेस से पुराने नाम के साथ फ़ील्ड को हटा दें और एक नए के साथ एक नया जोड़ें। बेशक, यह एनोटेशन में पुराने_नाम फ़ील्ड को जोड़कर भी पीटा जा सकता है, लेकिन मुझे ऐसा लग रहा था कि यह पहले से ही बहुत अधिक था, और ओआरएम उसे ठीक-ठीक बता सकता है कि उसे क्या करना है। पूर्वगामी के प्रकाश में, इस अनुच्छेद में, हमें नाम बदलने की विधि की आवश्यकता है:

 OrmUtils.UpdateTable(Car.class).renameColumn("old_column_name", "new_column_name"); 

ध्यान दें कि आपको कॉलम का नाम निर्दिष्ट करना होगा, न कि फ़ील्ड! परिणामस्वरूप, orm डेटाबेस में पूरे वर्ग और सभी फ़ील्ड्स को ऊन नहीं करेगा ताकि यह समझने के लिए कि उसे क्या बदलना है, लेकिन केवल एक एकल कॉलम के नाम में परिवर्तन करें।
हम उसे एक कॉलम जोड़ने में भी मदद कर सकते हैं:

 OrmUtils.UpdateTable(Car.class).addColumn("column_name"); 

और कॉलम हटाएं:

 OrmUtils.UpdateTable(Car.class).deleteColumn(“column_name”); 

एक sql क्वेरी के रूप में खुद का नाम बदलने से कुछ सवाल उठे। सबसे पहले, मैंने यह तय किया, जैसे हटाने के लिए, इच्छित फ़ील्ड नाम के साथ एक नई तालिका बनाकर, जहां पुराने से डेटा कॉपी किया जाता है, और इसे बस हटा दिया जाता है, और नया नाम बदल दिया जाता है। लेकिन फिर, मैं इस लेख में आया और इस पद्धति की कोशिश करने की योजना बना रहा हूं।

फ़ील्ड प्रकार बदलें

ओआरएम, फिर से, आपके लिए सब कुछ कर सकता है, लेकिन आप उसकी मदद कर सकते हैं:

 OrmUtils.UpdateTable(Car.class).changeColumnType("column_name"); 

सिद्धांत रूप में, दूसरा पैरामीटर अभी भी एक नए प्रकार के कॉलम को पारित कर सकता है, लेकिन मैं प्रोग्रामर को गलत प्रकार निर्दिष्ट करने का अवसर नहीं देना चाहता था, और फिर ऑर्म (:-)) डांटता था । पुराने प्रकार के डेटा की असंगति की समस्या और नए को डेटाबेस द्वारा स्वयं हल किया जाता है, पुरानी तालिका को नए पर कॉपी करते समय अपवाद को फेंक देता है। लेकिन दूसरे पैरामीटर के रूप में कॉलम को सही तरीके से पास करके आसानी से रीसेट किया जा सकता है:

 OrmUtils.UpdateTable(Car.class).changeColumnType(“column_name”, true); 

डिजाइन में एक पैरामीटर भी था जो इंगित करता है कि केवल प्रकार की असंगति के मामले में क्षेत्र को साफ किया जाना चाहिए, लेकिन अभी तक नहीं किया गया है।

निष्कर्ष

ये परिवर्तन हैं UCAOrm पिछले दो हफ्तों में आया है। जीथब को सब कुछ अपलोड नहीं किया गया है, क्योंकि, जैसा कि मैंने थोड़ा ऊपर लिखा था, अपडेटर पर काम अभी भी चल रहा है, और अभी तक सब कुछ परीक्षण नहीं किया गया है। तालिकाओं के प्रारंभिक निर्माण को थोड़ा सरल बनाने का भी विचार है: बस OrmUtils पर createByPackeg पद्धति को कॉल करके , उस पैकेज के नाम से गुजरते हुए जिसमें orm चिह्नित कक्षाओं की खोज करेगा। लेकिन यह केवल एक विचार है।
हमेशा की तरह, मैं किसी भी नए विचारों और सुझावों के लिए खुश रहूंगा। अपडेट के लिए जल्द बने रहें।