This answer expounds on the case described in the comments by Riley Dutton about the error message being misleading.
The error message will display when you pass an object which is not a subclass of NSManagedObject to deleteObject:
. Riley hit the problem simply by passing in the wrong object explicitly, but I got there by Core Data changes.
My project deployment target was set to 7.0, and this code worked without errors even running on iOS 9.3:
NSArray *entries = @[self.colorList.colors, self.emotionList.emotions, self.shapeList.shapes];
for (id entry in entries) {
[[self managedObjectContext] deleteObject:entry];
}
When I updated the project deployment target to 9.3, I started getting the error message.
Here is the description of entry
:
Relationship 'colors' fault on managed object (0x7fd063420310) <MyColorList: 0x7fd063420310> (entity: MyColorList; id: 0xd000000000640006 <x-coredata://12556DEF-F77E-4EFF-AAE6-55E71A3F5420/MyColorList/p25> ; data: {
attachedThing = "0xd0000000000c0004 <x-coredata://12556DEF-F77E-4EFF-AAE6-55E71A3F5420/MyThing/p3>";
colors = "<relationship fault: 0x7fd063468f30 'colors'>";
})
It looks like Apple changed the rules for when Core Data will trigger a fault and actually pull the data from the persistent store coordinator.
This modification solved the problem:
NSArray *entries = @[self.colorList.colors, self.emotionList.emotions, self.shapeList.shapes];
for (id entry in entries) {
for (id e in entry) {
[[self managedObjectContext] deleteObject:e];
}
}
At this time I do not know if this is the ideal way to solve this problem or if there is a more canonical way to tell Core Data to trigger the fault and read the data from disk.