5

मेरे पास NSManagedObjectContext के दो उदाहरण हैं: एक मुख्य थ्रेड में उपयोग किया जाता है और दूसरा पृष्ठभूमि थ्रेड में उपयोग किया जाता है (NSOperation के माध्यम से।) थ्रेड सुरक्षा के लिए, ये दो संदर्भ केवल NSPersistentStoreCoordinator साझा करते हैं।साझा लगातार स्टोर के साथ NSManagedObjectContexts के बीच लंबित परिवर्तनों की प्रतिलिपि बनाना?

मेरी समस्या में पहले संदर्भ (मुख्य धागे पर) लंबित परिवर्तनों के साथ है, जो -save तक दूसरे संदर्भ में उपलब्ध नहीं है। यह समझ में आता है क्योंकि साझा लगातार स्टोर में NSManagedObjects की प्रतियां -insertedObjects, -updatedObjects, और -deletedObjects द्वारा ट्रैक की जा रही हैं।

दुर्भाग्यवश, यह उपयोगकर्ता अनुभव के साथ एक समस्या प्रस्तुत करता है: किसी भी सहेजे गए परिवर्तन पृष्ठभूमि थ्रेड में उत्पन्न (समय लेने वाली) रिपोर्ट में प्रकट नहीं होंगे।

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

उत्तर

4

यदि यह 10.7 से कम है तो कुछ समाधान हैं: एक है कि आप प्रबंधित ओब्जेक्ट कॉन्टैक्स को नेस्टेड कर सकते हैं, ताकि आप संशोधित किए जा सकने वाले में "सेव" कर सकें और यह डिस्क पर सभी तरह से सहेज नहीं पाएगा, लेकिन यह मास्टर संदर्भ के अन्य बच्चों के लिए उपलब्ध परिवर्तन।

10.7 से पहले आपको शायद अपने आप में बदलावों की प्रतिलिपि बनाना होगा। यह बहुत कठिन नहीं है क्योंकि आप NSManagedObjectContextObjectsDidChangeNotification के लिए केवल एक ऑब्जेक्ट सुन सकते हैं और फिर मुख्य संदर्भ से बिल्कुल परिवर्तनों को फिर से लागू कर सकते हैं। (कोड की लगभग 20 पंक्तियां होनी चाहिए।) मुझे यह दूसरा संदर्भ कभी नहीं सहेजना होगा?

+0

धन्यवाद विल! मैं 10 को लक्षित करना चाहता हूं।6, कि कठिन हो रही है, हालांकि हर दिन :-) - मैं पहले से ही परिवर्तन सूचना ट्रैकिंग हूँ, लेकिन मुझे यकीन है कि कैसे आप परिवर्तन फिर से लागू करने और इकाई संबंधों को बनाए रखने नहीं कर रहा हूँ। क्या आप थोड़ा और स्पष्ट कर सकते हैं? – chockenberry

+0

आह हाँ। मैं अदृश्य रूप से अपने मॉडल के आधार पर एक धारणा बना रहा था, जो कि प्रत्येक ऑब्जेक्ट में यूयूआईडी (स्ट्रिंग) कुंजी है जिसे आपने स्वयं बनाए रखा है। –

+0

पृष्ठभूमि एमओसी में बचाने आवेषण मुख्य एमओसी (नेस्टेड MOCs के बिना) के लिए नहीं दिखाई देंगे बिना। अद्यतन/मौजूदा वस्तुओं के लिए मिटा दिया है तो आप परिवर्तन सूचना (processPendingChanges के बाद जारी) को सुनने के काम करते हैं और वस्तुओं खुद को अपडेट करना चाहिए। – diederikh

2

सुनिश्चित नहीं है कि आपके पास कोई ओएस संयम है लेकिन आईओएस 5/मैक ओएस 10.7 में आप इसे पूरा करने के लिए नेस्टेड प्रबंधित ऑब्जेक्ट संदर्भों का उपयोग कर सकते हैं। मेरा मानना ​​है कि एक बाल संदर्भ माता-पिता में बस एक नया लाने के द्वारा सहेजे गए परिवर्तनों को खींचने में सक्षम है।

संपादित करें: ऐसा लगता है कि Wil iOS 5/मैक ओएस 10.7 के लिए यह करने के लिए मुझे हरा लेकिन हाँ, पहले आप NSManagedObjectContextDidSaveNotification के लिए सुनने और के लिए जोड़ा/अद्यतन/नष्ट कर दिया userInfo शब्दकोश पर एक नज़र लेने के लिए होगा वस्तुओं।

0

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

0

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

अपने संस्थाओं में विशेषताओं के साथ उन समस्याओं को सुलझाने और मेल खाता हुआ predicated आसान होगा साथ पृष्ठभूमि सूत्र में क्वेरी करने ...

और वह एक स्थायी समाधान के रूप में अच्छी तरह से किया जाएगा। मैं डेटाबेस संचालित दुनिया (ऑरैकल) से आ रहा हूं, हम अक्सर अन्य डीबी सत्रों (जो एक कोको ऐप में थ्रेड के बराबर होगा) को दृश्यमान/अदृश्य बनाने के लिए ऐसे पैटर्न (रिकॉर्ड में स्थिति गुण) का उपयोग करते हैं। समस्याओं के बिना हमेशा काम करता है। अन्य धागे/सत्र हमेशा केवल संशोधित परिवर्तन देखते हैं कि अधिकांश आरडीबीएमएस कैसे काम करते हैं।

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