And I forgot to mention: the persistent store seems to get saved since when I restart the app (it's unusable after the CoreData error) the removed entities are not present. Curiouser and curiouser.
Martin On 10, Jan, 2013, at 06:05 PM, Martin Hewitson <martin.hewit...@aei.mpg.de> wrote: > > On 9, Jan, 2013, at 04:26 PM, Mike Abdullah <cocoa...@mikeabdullah.net> wrote: > >> >> On 8 Jan 2013, at 05:53, Martin Hewitson wrote: >> >>> >>> On Jan 7, 2013, at 08:44 PM, Mike Abdullah <cocoa...@mikeabdullah.net> >>> wrote: >>> >>>> >>>> On 7 Jan 2013, at 16:35, Martin Hewitson <martin.hewit...@aei.mpg.de> >>>> wrote: >>>> >>>>> Hi Francisco, >>>>> >>>>> Thanks for the feedback! >>>>> >>>>> What you suggest sounds like it might fix the problem, but I'm wondering >>>>> how best to do this. Currently I'm just calling -remove: on the tree >>>>> controller to delete the selected object(s). Of course, if I clear the >>>>> selection first, then -remove: doesn't do anything. I can grab an array >>>>> of the selected objects before clearing the selection then use >>>>> NSManagedObjectContext's -deleteObject:. So something like this: >>>>> >>>>> // get a pointer to the selected items >>>>> NSArray *items = [self selectedObjects]; >>>>> >>>>> // clear selection >>>>> [self setSelectionIndexPaths:@[]]; >>>>> >>>>> // now delete from the MOC >>>>> for (NSManagedObject *item in items) { >>>>> [self.managedObjectContext deleteObject:item]; >>>>> [self.managedObjectContext processPendingChanges]; >>>>> } >>>>> >>>>> Does that look sensible to you? >>>> >>>> Why are you calling -processPendingChanges at each iteration of the loop? >>>> Calling it yourself is rarely needed, and best done only with >>>> justification. >>>> >>> >>> I read in that thread that I referenced (I think) that it may be necessary >>> to do this to avoid/handle objects being deleted twice (if a parent and >>> child are selected, then deleted). To be honest, I'm just trying things to >>> see what works. Since this problem only occurs on 10.6.8, I think I'm >>> looking for a work-around. >> >> Hmm. In my case I go to some lengths to figure out which objects don't need >> to be deleted, because an ancestor has already been deleted. It does seem >> simpler your way. >> >> I wonder though — I don't believe there is any harm in asking Core Data to >> delete an object that's already been marked for deletion. And indeed, you >> code is doing that. The difference the -processPendingChanges call makes is >> that handling the delete rule will happen during that call, so child objects >> are already marked for deletion. >> > > However, I'm still not able to get this to work on 10.6.8. Having the > -processPendingChanges call seems to make no difference. > > The code I currently have in my -remove: method of the NSTreeController > subclass is > > // get a pointer to the selected items > NSArray *items = [self selectedObjects]; > > // clear selection > [self.outlineView selectRowIndexes:[NSIndexSet indexSet] > byExtendingSelection:NO]; > [self setSelectionIndexPaths:@[]]; > > // now from the MOC > for (NSManagedObject *item in items) { > [self removeObjectAtArrangedObjectIndexPath:[self > indexPathToObject:item]]; > [self.managedObjectContext deleteObject:item]; > [self.managedObjectContext processPendingChanges]; > } > > (-indexPathToObject: comes from a category NSTreeController_Extensions.h from > Jonathan Dann) > > Despite this, I must still have a reference to a deleted object somewhere, > but I've no idea where. Could there be other reasons for getting the > "CodeData could not fulfull a fault" error? > > Best wishes, > > Martin > > > > _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com