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
