2012-05-11 13 views
78

CoreData इकाई "ए" के पास CoreData प्रविष्टियों "बी" के संग्रह से एक से अधिक संबंध हैं, एक कैस्केड डिलीट नियम का उपयोग करते हुए।कोरडाटा + iCloud + कैस्केड हटाएं - कैसे संभालें?

iCloud पर्यावरण में, जबकि डिवाइस 1 "बी" प्रविष्टियों में से एक के बारे में विस्तृत विवरण दिखाता है, डिवाइस 2 "ए" प्रविष्टि को हटा देता है।

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

हालांकि, हालांकि "ए" प्रविष्टि वास्तव में शून्य हो जाती है जब विस्तार दृश्य नियंत्रक आंतरिक अधिसूचना प्राप्त करता है, प्रविष्टि "बी" अभी भी मान्य CoreData ऑब्जेक्ट के रूप में मौजूद है। ऐसा लगता है कि कैस्केड नियम ने अभी तक अपना ऑपरेशन पूरा नहीं किया है। इसलिए डिवाइस 1 में व्यू कंट्रोलर को डिलीट के बारे में पता नहीं है, जिससे अप्रत्याशित परिणाम हो सकते हैं।

mergeChangesFromContextDidSaveNotification आधार डेटा को विलय कर दिया गया है, लेकिन कैस्केड नियम अभी तक पूरा नहीं हुआ है, समय से पहले वापस आ रहा है।

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

इस बिंदु पर null प्रविष्टि "ए" प्रविष्टि एक विकल्प नहीं है, क्योंकि स्थिति यहां वर्णित की तुलना में कुछ अधिक जटिल है और कुछ मामलों में एक शून्य प्रविष्टि "ए" मान्य हो सकती है।

मैंने परिवर्तनों को विलय करने और दृश्य नियंत्रकों को आंतरिक अधिसूचना भेजने से पहले देरी शुरू करने का प्रयास किया। मुझे पता चला कि 2-सेकंड की देरी से मदद नहीं मिलती है, लेकिन 10-सेकंड की देरी काम करती है।

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

क्या कोई सही बात है? या मैं शुरू करने के लिए कुछ गलत कर रहा हूँ?

+0

ऐसा लगता है कि कैस्केड डिलीट्स जितनी जल्दी हो सके उतने ही प्रचारित होते हैं: प्रक्रिया पेंडिंग चेंज, रन लूप चक्र को सहेजना या समाप्त करना। सामान्य परिस्थितियों में आपके द्वारा वर्णित समस्या मौजूद नहीं होनी चाहिए। – svena

+0

NSPersistentStoreDidImportUbiquitousContentChangesNotification के साथ आता है जो NSDeletedObjectsKey सरणी में विस्तार दृश्य नियंत्रक में ऑब्जेक्ट के लिए प्रबंधित ऑब्जेक्ट आईडी है? – ImHuntingWabbits

+0

क्या यह हमेशा होता है या यह अस्थायी है? मेरे पास एक जटिल पदानुक्रमिक संरचना है और अभी तक कोई अनाथ नहीं देखा है! क्या आप इकाई बी को फिर से ला रहे हैं, या ऐसा हो सकता है क्योंकि आप इसे किसी भी तरह प्रदर्शित कर रहे हैं, आप ऑब्जेक्ट का संदर्भ बनाए रखते हैं। क्या होता है यदि आप ऐप बंद करते हैं और इसे फिर से खोलते हैं, तो यह इकाई बी अभी भी वहां है? –

उत्तर

1

अनुभव से, NSManagedObjectContextDidSaveNotification के अलावा अधिसूचनाओं को सुनना एक बड़ी गड़बड़ है और अभी तक अपडेट नहीं किए गए गुणों पर भरोसा कर सकता है। विस्तार दृश्य नियंत्रक को NSManagedObjectContextDidSaveNotification नोटिफिकेशन सुनना चाहिए, जिसे कैस्केड लागू करने के बाद फेंक दिया जाता है। यदि आप वर्तमान ऑब्जेक्ट मान्य हैं या नहीं (तो आप यह देखने के लिए जांच सकते हैं कि वर्तमान ऑब्जेक्ट का प्रबंधित ऑब्जेक्ट संदर्भ nil है या आप एक fetch कर सकते हैं और देख सकते हैं कि ऑब्जेक्ट स्टोर में मौजूद है या नहीं)।

संबंधित मुद्दे