There's no error or log at all, unless I set the merge policy to the default, in which case the error parameter contains what I expect it to contain: a conflict list with the right objects and properties that I expect to be in conflict. I understand the error coming back from the save, but not the call to objc_exception_throw.
In case it matters, this is on iPhone OS 3.1.3, Xcode 3.2.2. Thanks, Hank On Jun 8, 2010, at 12:08 PM, Alexander Spohr wrote: > Is there anything in the log? > What does save's error parameter return? > > atze > > > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
