OK, I tried with the MOC's undoManager set to nil, but the problem persists. Most annoying. I'll keep digging and post back if I discover anything.
Martin On 10, Jan, 2013, at 06:46 PM, Peter <magn...@web.de> wrote: > > Am 10.01.2013 um 18:38 schrieb Martin Hewitson: > >> >> On 10, Jan, 2013, at 06:25 PM, Peter <magn...@web.de> wrote: >> >>> >>> Am 10.01.2013 um 18:06 schrieb Martin Hewitson: >>> >>>> 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. >>> >>> What about the undo manager - if you are using undo? >> >> I think the MOC handles its own undo manager, right? At least I'm not doing >> handling it myself and I can undo the deletions. But surely the MOC will >> take care of deletion and undo properly, won't it? > > Im am not sure what happens under which condition in CoreData under 10.6.8. I > had a similar issue with an array controller involved. Maybe you should try > setting it to nil and see if the problem persists. > >> Martin >> >>> >>>>> 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