Menu
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.
640
A managed object context is an instance of NSManagedObjectContext . Its primary responsibility is to manage a collection of managed objects. These managed objects represent an internally consistent view of one or more persistent stores.
You cannot pass NSManagedObjects between multiple contexts, but you can pass NSManagedObjectIDs and use them to query the appropriate context for the object represented by that ID.
Most apps need just a single managed object context. The default configuration in most Core Data apps is a single managed object context associated with the main queue. Multiple managed object contexts make your apps harder to debug; it's not something you'd use in every app, in every situation.
Managed Object ContextThe NSManagedObjectContext class isn't thread safe. Plain and simple. You should never share managed object contexts between threads. This is a hard rule you shouldn't break.
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.
133
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.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
