insertNewObjectForEntityForName:inManagedObjectContext: returning NSNumber bug?

Question

I'm relatively well versed in CoreData and have been using it for several years with little or no difficulty. For the life of me, I can't figure out why

insertNewObjectForEntityForName:inManagedObjectContext:

is all of a sudden returning some sort of strange instance of NSNumber. GDB says the returned object is of the correct custom subclass of NSManagedObject, but when I go to print a description of the NSManagedObject itself, I get the following error:

*** -[NSCFNumber objectID]: unrecognized selector sent to instance 0x3f26f50

What's even stranger, is that I'm able to set some relationships and attributes using setValue:forKey: and all is good. But when I try to set one specific relationship, I get this error:

*** -[NSCFNumber entity]: unrecognized selector sent to instance 0x3f26f50

I've tried everything from clean all targets, to restarting both mac and iPhone, even editing the model so that the relationship in question is to-one instead of to-many. No matter what I do, the same problem appears. Has anyone ever seen anything like this before?

Answer 1

I had the very same issue: I had added a method called "isDatabase" (returning a BOOL) to the parent entity of my Database entity, which had a relationship named "database". Renaming "isDatabase" to "isOfTypeDatabase" fixed the issue. So keep also looking in parent entities!

Answer 2

I defined a property on an NSManagedObject subclass that collided with the name of a relationship defined on the class.

Here's the code in my MyManagedObjectSubclass+Custom.h

@property (readonly, nonatomic) BOOL isSeason;

Here's the code produced by XCode for MyManagedObjectSubclass.h

@property (nonatomic, retain) SomeOtherEntityToOneRelationship *season;

Note that isSeason, by KVC, will collide with the season name

Answer 3

I ran into the exact same problem and after pulling my hair out for an entire day, I solved my problem.

I believe the problem is related to a corrupt attribute / relationship, and the NSCFNumber is actually looking for the objectID for that attribute / relationship. In my case, I could use valueForKey: to find all of the attributes / relationships, although a relationship I had called "file" seemed to be corrupt.

I finally realized that I had extended NSObject to include a boolean "isFile" method, and somehow this was interfering with CoreData and causing it to either return a corrupt object, or not be able to deal properly with the object it had. My guess is that CoreData must dynamically create "isXXX" methods.

I could either fix the problem by removing the isFile method, or by renaming my property.