Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
OK, finally near the bottom of this problem. It turned out that I had an override of -didTurnIntoFault in my tree item entity. In there I was nil'ing out a couple of relationships (which are in principle nil'ed out by the nullify delete rule) - I did this while trying to track down some other document closing bug. These 3 lines of code made it into my test app, so I saw the problem there too. It's not clear to me why doing this caused this problem on 10.6.8 (and not on 10.7 or 10.8) but the Apple support guy said I shouldn't do it in -didTurnIntoFault. Anyway, removing that override (which is not needed anyway) fixes the problem. Simple when you know! Best wishes, Martin On Jan 15, 2013, at 05:41 PM, Martin Hewitson martin.hewit...@aei.mpg.de wrote: On 14, Jan, 2013, at 03:31 PM, Jerry Krinock je...@ieee.org wrote: Will -autorelease work with ARC? I don't think so. I didn't realize you were using ARC. I suppose you could opt out of ARC in your Method Replacement file, in order to compile that -autorelease. Could you hint how to do that? A category on NSTreeController? I can't find the article on Apple's site any more, but here it is from the horses's mouth, probably written better… http://mikeash.com/pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html Method Replacement is a good occasional last resort, particularly in troubleshooting, but you can ship it if necessary. Thanks for the pointers. Though after some further work, the test app now has only a very few lines of custom code, and the 'bug' is still there. The use of [NSTreeController selectedObjects] is gone, so that was a red herring (though the retaining may still be going on behind the scenes). So I've opened a ticket with Apple to get some support. I'll post back if they come up with a solution. Many thanks, Martin Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ___ 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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
On 14, Jan, 2013, at 03:31 PM, Jerry Krinock je...@ieee.org wrote: Will -autorelease work with ARC? I don't think so. I didn't realize you were using ARC. I suppose you could opt out of ARC in your Method Replacement file, in order to compile that -autorelease. Could you hint how to do that? A category on NSTreeController? I can't find the article on Apple's site any more, but here it is from the horses's mouth, probably written better… http://mikeash.com/pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html Method Replacement is a good occasional last resort, particularly in troubleshooting, but you can ship it if necessary. Thanks for the pointers. Though after some further work, the test app now has only a very few lines of custom code, and the 'bug' is still there. The use of [NSTreeController selectedObjects] is gone, so that was a red herring (though the retaining may still be going on behind the scenes). So I've opened a ticket with Apple to get some support. I'll post back if they come up with a solution. Many thanks, 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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
On Jan 13, 2013, at 9:32 PM, Jerry Krinock je...@ieee.org wrote: You've established previously that this is definitely a bug in Mac OS 10.6. I'm not sure I had reached that decision. I have now been able to reproduce the problem with a bare-bones core data document app. But still I wonder if it is something to do with my model (which is now a fraction of the model from the original app). I notice on 10.8 that if I remove an object from the tree controller then I have to hit save twice to make the 'document dirty' spot disappear, hinting that there is something still wrong on 10.8, but it's swept under the carpet, whereas on 10.6.8 it isn't. Your mission is to find a workaround. Maybe - see above. On 2013 Jan 12, at 23:29, Martin Hewitson martin.hewit...@aei.mpg.de wrote: 2) Whenever I do [NSTreeController selectedObjects] I seem to end with an additional reference count. Is that expected? If you mean that there is an additional reference count long after the time when the object is no longer in use, which apparently prevents its deallocation, definitely not. Furthermore, if you are saying that the excess reference count is proportional to the number of times that [NSTreeController selectedObjects] is invoked, maybe the bug in Mac OS 10.6 is a memory leak in -[NSTreeController selectedObjects]. Try doing a Method Replacement on that method. In your replacement implementation, invoke the original method, then invoke -autorelease. Could you hint how to do that? A category on NSTreeController? Will -autorelease work with ARC? I'm not sure how this would cause a Core Data could not fulfill a fault exception, except that allowing dead managed objects to hang around is not a good thing. That's a bit my problem too. Mixed metaphors not withstanding, I wonder if I'm just following a red herring down a dead end. I'll keep digging at my bare bones test app to see if I can fix the issue. Maybe the next step is to drop back from an outlineview+treecontroller to a table+arraycontroller. Thanks again for your thoughts, Martin p.s. I could post the test app if anyone wishes to see it. ___ 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/martin.hewitson%40aei.mpg.de This email sent to martin.hewit...@aei.mpg.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
Will -autorelease work with ARC? I don't think so. I didn't realize you were using ARC. I suppose you could opt out of ARC in your Method Replacement file, in order to compile that -autorelease. Could you hint how to do that? A category on NSTreeController? I can't find the article on Apple's site any more, but here it is from the horses's mouth, probably written better… http://mikeash.com/pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html Method Replacement is a good occasional last resort, particularly in troubleshooting, but you can ship it if necessary. ___ 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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
You've established previously that this is definitely a bug in Mac OS 10.6. Your mission is to find a workaround. On 2013 Jan 12, at 23:29, Martin Hewitson martin.hewit...@aei.mpg.de wrote: 2) Whenever I do [NSTreeController selectedObjects] I seem to end with an additional reference count. Is that expected? If you mean that there is an additional reference count long after the time when the object is no longer in use, which apparently prevents its deallocation, definitely not. Furthermore, if you are saying that the excess reference count is proportional to the number of times that [NSTreeController selectedObjects] is invoked, maybe the bug in Mac OS 10.6 is a memory leak in -[NSTreeController selectedObjects]. Try doing a Method Replacement on that method. In your replacement implementation, invoke the original method, then invoke -autorelease. I'm not sure how this would cause a Core Data could not fulfill a fault exception, except that allowing dead managed objects to hang around is not a good thing. ___ 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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
Now that I know how to get instruments to track retains and releases, I can see what is happening to my entity. I'm still uncertain how to interpret the results, but I see two strange things in the history of the object being deleted: 1) It has a reference count of 3 after all the deletion stuff has finished 2) Whenever I do [NSTreeController selectedObjects] I seem to end with an additional reference count. Is that expected? In the end, I'm struggling to see if this could be the cause of my CoreData could not fulfil fault bug. Since I can't reproduce this on my development machine (10.8) and it only shows up on 10.6.8, it's proving difficult to track down. Anyone have any other ideas? Or can anyone see the problem in the history of the object dumped below? Yours in abject frustration, Martin # Address CategoryEvent Type RefCt Timestamp Size Responsible Library Responsible Caller 0 0x1031c4bd0 FolderEntity_Folder_Malloc 1 00:10.760.480 112 CoreData_PFAllocateObject 1 0x1031c4bd0 FolderEntity_Folder_Retain 2 00:10.760.709 0 CoreData-[NSManagedObjectContext(_NSInternalAdditions) _insertObjectWithGlobalID:globalID:] 2 0x1031c4bd0 FolderEntity_Folder_Retain 3 00:10.761.328 0 CoreData_sharedIMPL_setvfk_core 3 0x1031c4bd0 FolderEntity_Folder_Release 2 00:10.761.358 0 CoreData_PF_ManagedObject_DidChangeValueForKeyIndex 4 0x1031c4bd0 FolderEntity_Folder_Retain 3 00:10.763.708 0 Foundation -[NSObject(NSDelayedPerforming) performSelector:withObject:afterDelay:inModes:] 5 0x1031c4bd0 FolderEntity_Folder_Retain 4 00:10.763.726 0 TeXnicle-[ProjectItemTreeController addFolder:withFilePath:createOnDisk:] 6 0x1031c4bd0 FolderEntity_Folder_Release 3 00:10.763.726 0 TeXnicle-[ProjectItemTreeController addFolder:withFilePath:createOnDisk:] 7 0x1031c4bd0 FolderEntity_Folder_Autorelease 00:10.763.729 0 TeXnicle-[ProjectItemTreeController addFolder:withFilePath:createOnDisk:] 8 0x1031c4bd0 FolderEntity_Folder_Retain 4 00:10.763.730 0 TeXnicle-[ProjectItemTreeController addNewFolder] 9 0x1031c4bd0 FolderEntity_Folder_Release 3 00:10.763.730 0 TeXnicle-[ProjectItemTreeController addNewFolder] 10 0x1031c4bd0 FolderEntity_Folder_Retain 4 00:10.776.907 0 CoreData-[NSManagedObjectContext(_NSInternalChangeProcessing) _processPendingInsertions:withDeletions:withUpdates:] 11 0x1031c4bd0 FolderEntity_Folder_Retain 5 00:10.776.909 0 CoreData-[NSManagedObjectContext(_NSInternalChangeProcessing) _processPendingInsertions:withDeletions:withUpdates:] 12 0x1031c4bd0 FolderEntity_Folder_Retain 6 00:10.776.911 0 CoreData-[NSManagedObjectContext(_NSInternalChangeProcessing) _processPendingInsertions:withDeletions:withUpdates:] 13 0x1031c4bd0 FolderEntity_Folder_Release 5 00:10.777.108 0 CoreData-[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] 14 0x1031c4bd0 FolderEntity_Folder_Retain 6 00:10.777.255 0 AppKit -[_NSManagedProxy _managedObjectsChangedInContext:] 15 0x1031c4bd0 FolderEntity_Folder_Retain 7 00:10.777.315 0 AppKit -[NSTreeController(NSManagedController) _reactToMatchingInsertions:deletions:refreshed:] 16 0x1031c4bd0 FolderEntity_Folder_Retain 8 00:10.777.319 0 AppKit -[NSTreeController(NSManagedController) _reactToMatchingInsertions:deletions:refreshed:] 17 0x1031c4bd0 FolderEntity_Folder_Retain 9 00:10.777.732 0 Foundation -[NSArray(NSKeyValueSorting) sortedArrayUsingDescriptors:] 18 0x1031c4bd0 FolderEntity_Folder_Retain 10 00:10.777.846 0 AppKit -[NSTreeNode setRepresentedObject:] 19 0x1031c4bd0 FolderEntity_Folder_Retain 11 00:10.779.008 0 TeXnicle-[ESOutlineView reloadData] 20 0x1031c4bd0 FolderEntity_Folder_Release 10 00:10.779.011 0 TeXnicle-[ESOutlineView reloadData] 21 0x1031c4bd0 FolderEntity_Folder_Release 9 00:10.779.083 0 AppKit -[_NSManagedProxy _managedObjectsChangedInContext:] 22 0x1031c4bd0 FolderEntity_Folder_Release 8 00:10.779.133 0 CoreData-[NSManagedObjectContext(_NSInternalChangeProcessing) _processRecentChanges:] 23 0x1031c4bd0 FolderEntity_Folder_Release 7 00:10.779.169 0 Foundation -[NSAutoreleasePool drain] 24 0x1031c4bd0 FolderEntity_Folder_Release 6 00:10.779.178
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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?
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/magnard%40web.de
This email sent to magn...@web.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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?
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/magnard%40web.de
This email sent to magn...@web.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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/magnard%40web.de
This email sent to magn...@web.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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.
___
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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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?
Best wishes,
Martin
On 6, Jan, 2013, at 09:27 PM, Francisco Garza dubro...@icloud.com wrote:
Sorry, trying to respond to your message but goddamn Apple Mail...
I have an app which presents folders and files in a tree structure. I'm
using an NSTreeController and core data to keep track of the relationships
between the files and folders. The ProjectItem entity has a 'children'
relationship which is to-many with the same entity and a 'parent'
relationship which is to-one with the same entity. The 'children'
relationship has a cascade delete rule; the parent one has a nullify rule. I
use a tree-controller and then an outline view to display. Pretty normal
stuff so far.
I received a bug report from a user saying that when he deletes a folder
which contains one or more files then he can't save the document (this is an
NSPersistentDocument app, by the way). The error in the logs is
CoreData could not fulfil a fault for Folder/ ...
I've run into this bug before with NSArrayController -- basically the item is
selected, you delete it, then the NSTreeControllers/NSArrayController
maintains the selection and tries to access the object afterwards for some
reason, but the object is deleted and on 10.6 that throws an exception.
Obviously they fixed it in 10.7, but I found the workaround was to set the
array/tree controller's selection to empty BEFORE deleting the object. This
ensures that it won't get accessed. You can also manually remove the item (by
calling removeObject:) then call deleteObject:, which fixes the bug as well.
–F.G.
___
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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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.
___
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
Re: Cococa-Dev : was [coredata count not fulfill fault after object delete]
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.
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
