On Jun 8, 2010, at 1:24 PM, David Brown wrote: > Have you thought about avoiding the problem altogether? > > Instead of marking the objects and then needed to save them, write out a file > somewhere that identifies those objects, outside of core data. > > Then, when your app is starting, check for the presence of the file before > anything else happens, and take whatever actions you need to take to resume > the processing.
That's certainly a possible workaround. Core Data should be able to handle this though. When I relaunch my app, all the changes did propagate properly. Everything works in the Distribution build without warnings, errors, etc. It's just that objc_exception_throw gets called, and I'm wondering why. Is it a symptom of an unrelated problem that I'm not understanding yet, is it a bug in Core Data, or should I just not worry about it? Hank >>> Am 08.06.2010 um 17:53 schrieb Hank Heijink (Mailinglists): >>> >>>> Dear all, >>>> >>>> I've run into the following problem, and I'm a bit stuck - I wonder if you >>>> can shed some light on this. I have an iPhone app that uses Core Data, and >>>> the problem occurs when the app terminates. I have an NSOperationQueue >>>> with potentially several NSOperations that are cancelled in the >>>> applicationWillTerminate: UIApplication delegate method. >>>> >>>> These NSOperations all have their own copy of an NSManagedObjectContext >>>> and an NSManagedObject subclass (I pass them the persistent store >>>> coordinator and an NSManagedObjectID that is permanent at that point). >>>> >>>> Canceling the NSOperation changes an attribute of the NSManagedObject >>>> subclass and I save the NSManagedObjectContext on the background thread >>>> after this change is made. This means that the NSManagedObjectContext on >>>> the main thread is now in conflict, and since all this happens in >>>> applicationWillTerminate:, it won't receive the >>>> NSManagedObjectContextDidSaveNotification so it can deal with it. >>>> >>>> My solution to this is to set the merge policy to >>>> NSMergeByPropertyStoreTrumpMergePolicy right before saving the main >>>> NSManagedObjectContext to give precedence to the already-saved context(s). >>>> I haven't been able to find any information about this scenario - the Core >>>> Data Programming Guide (in Communicating Changes Between Contexts) seems >>>> to suggest my approach (case 3b), although there in-memory changes are >>>> preferred over store changes. >>>> >>>> I always have a break point set on objc_exception_throw, and it hits this >>>> breakpoint in the call to save. This is the stack backtrace: >>>> >>>> #0 0x986d94e6 in objc_exception_throw () >>>> #1 0x01dee37c in -[NSPersistentStoreCoordinator(_NSInternalMethods) >>>> executeRequest:withContext:] () >>>> #2 0x01e22afe in -[NSManagedObjectContext save:] () >>>> #3 0x000036b6 in -[MyAppDelegate applicationWillTerminate:] >>>> ...<snip>... >>>> >>>> However, if I remove the break point or hit continue, the application >>>> quits with an exit code of 0. If I wrap my [NSManagedObjectContext save] >>>> call in a @try @catch block, the @catch statements are never executed. So, >>>> is there an exception or isn't there? Should I rethink my approach? I'm >>>> just not sure what the issue is here. >>>> >>>> Any information is greatly appreciated! >>>> >>>> Thanks in advance, >>>> Hank_______________________________________________ >>>> >>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>>> >>>> Please do not post admin requests or moderator comments to the list. >>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>>> >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/cocoa-dev/atze%40freeport.de >>>> >>>> This email sent to a...@freeport.de >>> >>> >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/cocoa-dev/ddb%40bithead.net >> >> This email sent to d...@bithead.net > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
