कोर डेटा विस्तार से

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

मैं शुरुआत के साथ करता हूँ।

कोर डेटा एक ढांचा है जो किसी एप्लिकेशन में डेटा को प्रबंधित और संग्रहीत करता है। आप कोर डेटा को भौतिक संबंधपरक भंडारण पर एक आवरण के रूप में मान सकते हैं जो ऑब्जेक्ट के रूप में डेटा का प्रतिनिधित्व करता है, जबकि कोर डेटा स्वयं एक डेटाबेस नहीं है।

कोर डेटा ऑब्जेक्ट

संग्रहण बनाने के लिए, अनुप्रयोग NSPersistentStoreCoordinator या NSPersistentContainer वर्गों का उपयोग करता है। NSPersistentStoreCoordinator मॉडल के आधार पर निर्दिष्ट प्रकार का भंडारण बनाता है, आप स्थान और अतिरिक्त विकल्प निर्दिष्ट कर सकते हैं। NSPersistentContainer का उपयोग iOS10 के साथ किया जा सकता है, जो न्यूनतम मात्रा में कोड बनाने की क्षमता प्रदान करता है।

यह निम्नानुसार काम करता है: यदि कोई डेटाबेस निर्दिष्ट पथ पर मौजूद है, तो समन्वयक इसके संस्करण की जांच करता है और यदि आवश्यक हो, तो एक माइग्रेशन करता है। यदि डेटाबेस मौजूद नहीं है, तो यह NSManagedObjectModel मॉडल के आधार पर बनाया गया है। यह सब सही ढंग से काम करने के लिए, मॉडल में बदलाव करने से पहले, मेनू संपादक के माध्यम से Xcode में एक नया संस्करण बनाएं -> मॉडल संस्करण जोड़ें। यदि आपको रास्ता मिलता है, तो आप एमुलेटर में आधार ढूंढ सकते हैं और खोल सकते हैं।


कोर डेटा 4 प्रकार के भंडारण का उपयोग करता है:

- SQLite
- बाइनरी
- स्मृति में
- एक्सएमएल (केवल मैक ओएस)

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

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

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

विरासत

किसी कारण से मुझे समझ में नहीं आ रहा है, बहुत बड़ी संख्या में मैनुअल और उदाहरण हैं जहां Entity / NSManagedObject (तालिकाओं) के लिए उत्तराधिकार किसी भी तरह से उपयोग नहीं किया जाता है। इस बीच, यह एक बहुत ही सुविधाजनक उपकरण है। यदि आप इनहेरिटेंस का उपयोग नहीं करते हैं, तो आप केवल KVC तंत्र के माध्यम से विशेषताओं (फ़ील्ड्स) को मान असाइन कर सकते हैं, जो नाम और प्रकार की विशेषताओं की जाँच नहीं करता है, और यह आसानी से रनटाइम त्रुटियों को जन्म दे सकता है।

NSManagedObject के लिए वर्ग पुनर्वित्त कोर डेटा डिजाइनर में किया जाता है:

वंशानुक्रम और कोड पीढ़ी

इकाई का नाम निर्दिष्ट करने के बाद, आप कोड पीढ़ी का उपयोग कर सकते हैं और तैयार कोड के साथ एक वर्ग प्राप्त कर सकते हैं:





यदि आप ऑटोजेनरेटेड कोड देखना चाहते हैं, लेकिन प्रोजेक्ट में फ़ाइलों को जोड़ना नहीं चाहते हैं, तो आप दूसरे तरीके का उपयोग कर सकते हैं: एंटिटी के लिए "कोडगन" विकल्प सेट करें। इस स्थिति में, कोड को खोजा जाना चाहिए .. / DerivedData / ...



कक्षाएं बनाने के लिए कोड पीढ़ी का उपयोग करें, चर नामों में टाइपो रनटाइम त्रुटियों को जन्म दे सकता है।

यहाँ कुछ कोड इस प्रकार है:

 @objc public class Company: NSManagedObject {    @NSManaged public var inn: String?  @NSManaged public var name: String?  @NSManaged public var uid: String?  @NSManaged public var employee: NSSet? } 

स्विफ्ट में, @NSManaged का वही अर्थ है जो Objective C में डायनामिक है।
कोर डेटा स्वयं अपनी कक्षाओं की विशेषताओं के लिए डेटा प्राप्त करने (आंतरिक एक्सेसर्स) का ध्यान रखता है। यदि आपके पास पारगमन क्षेत्र हैं, तो आपको उन्हें गणना करने के लिए फ़ंक्शन जोड़ने की आवश्यकता है।

NSManagedObject (तालिकाओं) से विरासत में मिली कक्षाएं अन्य वर्गों के विपरीत, IOS10 से पहले "नियमित" कंस्ट्रक्टर नहीं थीं। प्रकार कंपनी का एक ऑब्जेक्ट बनाने के लिए, NSEntityDescription का उपयोग करते हुए एक अधिक अनाड़ी निर्माण लिखना आवश्यक था। अब संदर्भ के माध्यम से आरंभीकरण की एक और अधिक सुविधाजनक विधि है (NSManagedObjectContext)। कोड नीचे है। केवीसी तंत्र पर विशेषताएँ निर्दिष्ट करते समय विरासत के लाभ पर ध्यान दें:

 // 1 -    NSEntityDescription,    KVO let company1 = NSEntityDescription.insertNewObject(forEntityName: "Company", into: moc) company1.setValue("077456789111", forKey: "inn") company1.setValue(" ", forKey: "name") // 2 -    NSEntityDescription,     let company2 = NSEntityDescription.insertNewObject(forEntityName: "Company", into: moc) as! Company company2.inn = "077456789222" company2.name = " " // 3 -     (IOS10+),     let company3 = Company(context: moc) company3.inn = "077456789222" company3.name = " " 

NSManagedObject के लिए नाम स्थान

एक और बात ध्यान देने योग्य है नाम है।



यदि आप ObjectiveC या Swift पर काम कर रहे हैं तो आपको कोई कठिनाई नहीं होगी। आमतौर पर, यह फ़ील्ड डिफ़ॉल्ट रूप से सही ढंग से भरी जाती है। लेकिन मिश्रित परियोजनाओं में, यह आपके लिए एक आश्चर्य की बात हो सकती है कि स्विफ्ट और ऑब्जेक्टिव में कक्षाओं के लिए आपको अलग-अलग विकल्प देने होंगे। स्विफ्ट में, "मॉड्यूल" भरना होगा। यदि यह फ़ील्ड पूरी नहीं हुई है, तो प्रोजेक्ट नाम के साथ एक उपसर्ग को वर्ग नाम में जोड़ा जाएगा, जिससे रनटाइम त्रुटि होगी। ऑब्जेक्टिव सी में, "मॉड्यूल" को खाली छोड़ दें, अन्यथा NSManagedObject वर्ग के नाम के माध्यम से इसे एक्सेस करते समय नहीं मिलेगा।

वस्तुओं के बीच संबंध

सिद्धांत रूप में, रिश्तों का विषय अच्छी तरह से कवर किया गया है, लेकिन मैं इस बात पर ध्यान केंद्रित करना चाहता हूं कि माता-पिता के लिए बाल संस्थाओं को कैसे जोड़ा जाए। इसलिए, पहले, लिंक बनाने के लिए तंत्र का एक त्वरित अनुस्मारक। एक पारंपरिक उदाहरण पर विचार करें, एक कंपनी कर्मचारी है, एक-से-कई संबंध हैं:

• प्रत्येक पक्ष पर एक कनेक्शन बनाएं (तालिका)
• उसके बाद, उलटा क्षेत्र उपलब्ध हो जाता है, इसे प्रत्येक तालिका में भरना होगा।

Apple उलटे रिश्तों को निर्दिष्ट करने पर जोर देता है। एक ही समय में, उलटा सुसंगतता को मजबूत नहीं करता है, लेकिन कनेक्शन के दोनों किनारों पर कोर डेटा ट्रैक परिवर्तन में मदद करता है, यह कैशिंग और अद्यतन जानकारी के लिए महत्वपूर्ण है।

विलोपन नियम को सही ढंग से निर्दिष्ट करना भी महत्वपूर्ण है। विलोपन नियम एक क्रिया है जिसे इस ऑब्जेक्ट के साथ किया जाएगा जब मूल ऑब्जेक्ट हटा दिया जाता है।

• कैस्केड - सभी बाल वस्तुओं को हटाने, जब माता-पिता को हटा दिया जाता है।
• इनकार - यदि बच्चा है तो माता-पिता को हटाने का निषेध
• Nullify - मूल संदर्भ को nullify करें
• कोई कार्रवाई नहीं - कोई कार्रवाई निर्दिष्ट नहीं है, यह संकलन पर एक चेतावनी देगा

इस उदाहरण में, जब कोई कंपनी हटा दी जाती है, तो सभी कर्मचारियों को हटा दिया जाएगा (कैस्केड)। जब आप किसी कर्मचारी को हटाते हैं, तो कंपनी में उसका लिंक रीसेट हो जाएगा (प्री स्क्रीन)

माता-पिता के लिए बाल संस्थाओं को जोड़ने के तरीके

1) पहला तरीका एनएसएसईटी के माध्यम से जोड़ रहा है। उदाहरण के लिए, कंपनी में 2 कर्मचारी जोड़ें:

 let set = NSMutableSet();    if let employee1 = NSEntityDescription.insertNewObject(forEntityName: "Employee", into: moc) as? Employee { employee1.firstName = "" employee1.secondName = "" set.add(employee1) } if let emploee2 = NSEntityDescription.insertNewObject(forEntityName: "Employee", into: moc) as? Employee { employee2.firstName = "" employee2.secondName = "" set.add(employee2) }    company.employee = set 

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

 let set = company.mutableSetValue(forKey: "employee") 

2) माता-पिता आईडी के माध्यम से बच्चे की वस्तुओं को जोड़ना

 if let employee = NSEntityDescription.insertNewObject(forEntityName: "Employee", into: moc) as? Employee { employee.firstName = "" employee.secondName = "" employee.company = company } 

बच्चे के ऑब्जेक्ट को जोड़ने या संपादित करते समय दूसरी विधि सुविधाजनक है
अलग रूप।

3) ऑटो-जनरेट किए गए तरीकों के माध्यम से बच्चे की वस्तुओं को जोड़ना

 extension Company {    @objc(addEmployeeObject:)  @NSManaged public func addEmployee(_ value: Employee)    @objc(removeEmployeeObject:)  @NSManaged public func removeFromEmployee(_ value: Employee)    @objc(addEmployee:)  @NSManaged public func addEmployee(_ values: NSSet)    @objc(removeEmployee:)  @NSManaged public func removeFromEmployee(_ values: NSSet) } 

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

बाल खंड प्रश्न

कोर डेटा में, आप किसी भी डेटा के बीच मनमानी क्वेरी नहीं बना सकते हैं, जैसा कि हम SQL में कर सकते हैं। लेकिन निर्भर वस्तुओं के बीच, मानक विधेय का उपयोग करके ट्रैक करना आसान है। नीचे एक क्वेरी का उदाहरण दिया गया है, जिसमें उन सभी कंपनियों का चयन किया गया है, जिसमें निर्दिष्ट नाम वाला कर्मचारी है:

 public static func getCompanyWithEmployee(name: String) -> [Company] { let request = NSFetchRequest<NSFetchRequestResult>(entityName: self.className()) request.predicate = NSPredicate(format: "ANY employee.firstName = %@", name) do { if let result = try moc.fetch(request) as? [Company] { return result } } catch { } return [Company]() } 

कोड में विधि कॉल इस तरह दिखाई देगी:

 //  ,    let companies = Company.getCompanyWithEmployee(name: "") 

क्वेरी में ट्रांज़िट फ़ील्ड का उपयोग न करें, क्वेरी निष्पादित होने के समय उनके मूल्यों को परिभाषित नहीं किया जाता है। कोई त्रुटि नहीं होगी, लेकिन परिणाम गलत होगा।

सेटिंग विशेषताएँ (फ़ील्ड)

आपने शायद देखा है कि एंटिटी विशेषताओं के कई विकल्प हैं।
वैकल्पिक के साथ, नाम से सब कुछ स्पष्ट है।

स्केलर प्रकार का उपयोग करने का विकल्प स्विफ़ में दिखाई दिया। उद्देश्य-सी विशेषताओं के लिए स्केलर प्रकारों का उपयोग नहीं करते हैं, क्योंकि वे शून्य नहीं हो सकते हैं। KVC के माध्यम से किसी विशेषता को स्केलर मान निर्दिष्ट करने का प्रयास एक रनटाइम त्रुटि का कारण होगा। इससे यह स्पष्ट हो जाता है कि कोर डेटा में विशेषता प्रकार भाषा के प्रकार के साथ एक सख्त पत्राचार क्यों नहीं करते हैं। स्विफ्ट में, और मिश्रित परियोजनाओं में, स्केलर प्रकार की विशेषताओं का उपयोग किया जा सकता है।

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

सहायक अभिगमकर्ता:

यदि आपको गणना किए गए फ़ील्ड का उपयोग करने की आवश्यकता नहीं है, उदाहरण के लिए, एन्क्रिप्शन या कुछ और करने के लिए, तो आपको यह नहीं सोचना चाहिए कि विशेषता क्या हैं। इस बीच, विशेषताओं को मान प्राप्त करने और असाइन करने के संचालन "परमाणु" नहीं हैं। मेरे कहने का मतलब समझने के लिए, नीचे दिया गया कोड देखें:

 //  let name = company.name //  company.willAccessValue(forKey: "name") let name = company.primitiveValue(forKey: "name") company.didAccessValue(forKey: "name") //  company.name = " " //  company.willChangeValue(forKey: "name") company.setPrimitiveValue(" ", forKey: "name") company.didChangeValue(forKey: "name") 

लूपिंग से बचने के लिए सामान्य असाइनमेंट के बजाय NSManagedObject ईवेंट में प्राइमिटिव का उपयोग करें। एक उदाहरण:

 override func willSave() {   let nameP = encrypt(field: primitiveValue(forKey: "name"), password: password)   setPrimitiveValue(nameP, forKey: "nameC")   super.willSave() }  override func awakeFromFetch() {   let nameP = decrypt(field: primitiveValue(forKey: "nameC"), password: password)   setPrimitiveValue(nameP, forKey: "name")   super.awakeFromFetch() } 

यदि अचानक किसी समय आपको किसी प्रोजेक्ट में awakeFromFetch फ़ंक्शन को पेंच करना पड़ता है, तो आपको आश्चर्य होगा कि यह बहुत अजीब काम करता है, और वास्तव में अनुरोध को निष्पादित करते समय इसे बिल्कुल भी नहीं कहा जाता है। यह इस तथ्य के कारण है कि कोर डेटा में बहुत बुद्धिमान कैशिंग तंत्र है, और यदि चयन पहले से ही मेमोरी में है (उदाहरण के लिए, क्योंकि आपने इस तालिका को भर दिया है), तो विधि नहीं कहा जाएगा। हालाँकि, मेरे प्रयोगों से पता चला है कि परिकलित मूल्यों के संदर्भ में, आप सुरक्षित रूप से awakeFromFetch के उपयोग पर भरोसा कर सकते हैं, जैसा कि Apple के दस्तावेज कहते हैं। यदि परीक्षण और विकास के लिए आपको awakeFromFetch को बाध्य करने की आवश्यकता है, तो अनुरोध से पहले ManageObjectContext.refreshAllObjects () जोड़ें।

वह सब है।

अंत तक पढ़ने वाले सभी को धन्यवाद।