ManagedObject Seems to Lose Its Class Type, or Becomes a Different Type of Object

I'm experiencing the oddest behavior with a CoreData managed object. In my viewDidLoad method I do the following:

    NSPredicate *predicate =[NSPredicate predicateWithFormat:@"uuid = %@", self.imageUUID];
    NSFetchRequest *imageFetchRequest = [[[NSFetchRequest alloc] init] autorelease];
    [imageFetchRequest setPredicate:predicate];
    NSEntityDescription *imageEntity = [NSEntityDescription entityForName:@"Image" inManagedObjectContext:appDelegate.managedObjectContext];
    [imageFetchRequest setEntity:imageEntity];
    error = nil;
    NSArray *array = [[appDelegate managedObjectContext] executeFetchRequest:imageFetchRequest error:&error];

    tagImage = (Image *)[array objectAtIndex:0];
    assert([tagImage isKindOfCl开发者_运维知识库ass:[Image class]]);

The assertion passes. This particular view is a TableViewController and in my cellForRowAtIndexPath method, I need to check some of the Image properties. Anytime I access a property of tagImage, the application fails so I added another assertion as follows in this method:

assert([tagImage isKindOfClass:[Image class]]);

This time, the assertion fails. I have no idea what would be making the tagImage object change types.

Are you sure you are retaining the array or the managed objects ? It might happen that there are somehow released and that's why you have an error ?

Check your Image class is definitely included in your build target. I've seen instances where a fetch request returned vanilla NSManagedObjects rather than my own custom subclass because I had not included the class in the Logic Tests target I was running at the time.

As an aside, convention dictates you should be prefixing your class names with a two letter prefix of your choice (so something like MZImage in this case) to reduce the chances of a class name conflict. There's a fairly good chance of running into a class name conflict with a class name of Image.