Why doesn't NSManagedObject instances hold a strong reference to their NSManagedObjectContext?

Question

As pointed out in another question on SO (and the Apple docs), NSManagedObject instances do not hold a strong reference to the NSManagedObjectContext from which they originated. On first blush, this seems like a strange decision, since NSManagedObject instances are nearly useless without their context, since it leads to confusing bugs such as faults not firing when they should.

Can anyone provide some background on why this is the case? Would it be dangerous to implement an NSManagedObject subclass that automatically holds a strong reference to its NSManagedObjectContext?

Edit: thanks to great answers to this question, I've discovered that my managed objects were created against an intentionally temporary NSManagedObjectContext by RestKit. This follows into my next question, specific to RestKit, here.

Heartwarming

Answer 1

It makes more sense for an NSManagedObjectContext to own its NSManagedObjects than the other way around.

Keep in mind that the context is like a draw pad with all its objects on it. If that context goes away, the objects are no longer valid. If the objects owned the context, then the context going away would do nothing to the objects and they still appeared to be valid. In other words: a context can exist without objects, objects can't exist without a context.

Of course, a hybrid model (where a context owns its objects and objects own their context) wouldn't work either, because then you would run into a retain cycle.

NSManagedObject instances are nearly useless without their context

They can be (though not necessarily), but remember that they do have a reference to their context! Presumably it's a weak reference, but a reference nonetheless. If that reference returns nil, the object is invalid. If you make sure your context stays around (which is what I did in my answer to the other question), you won't have any issues.

Auricula

Answer 2

This is because you otherwise would get a retain cycle. The managed object context internally uses arrays and other containers which have references to the managed objects.

Possibly, this retain cycle cannot be "explicitly broken" that easily by the internal implementation of Core Data, so that this reference has to be weak.

Drought

CouchDeveloper is correct, and yes, it would be potentially dangerous to add a strong reference to the context from a managed object class. Faults not firing when they "should" can be due to many things, but most often it is an incorrect implementation of an accessor method. – Salami

Answer 3

Would it be dangerous to implement an NSManagedObject subclass that automatically holds a strong reference to its NSManagedObjectContext?

As others pointed out, this would be dangerous because you'd be creating a retain cycle.

A better practice would be to subscribe to the Notification

NSManagedObjectContextObjectsDidChange

Here you could update your objects whenever the context notifies you that it changed them.

Example:

- (void)addObservers
{
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(managedObjectContextChanged) name:NSManagedObjectContextObjectsDidChangeNotification object:_myManagedObjectContext];
}

- (void)managedObjectContextChanged
{
    [self fetchObjects];
}

Also, as Apple points out, be sure to pass the context you want to observe:

Several system frameworks use Core Data internally. If you register to receive these notifications from all contexts (by passing nil as the object parameter to a method such as addObserver(_:selector:name:object:)), then you may receive unexpected notifications that are difficult to handle.

Defazio