Should Reference to Core Data Object be Strong or Weak?

Question

I couldn't think of core data refer to anything outside coredata. So there is no way there will be reference cycle. At most core data object points to another coredata objects.

however, I may be wrong.

Managedobjectcontext do not hold strong reference to core data.

Is there any guide here?

Please clarify: Do you take care about "internal" retain cycles of objects inside a context or do you take care about "outer" references of your code to objects inside a context? — Amin Negm-Awad, May 10 '13 at 09:48
internal retain cycles inside a context? That is managed by core data entirely. Outer references of my code to objects inside a context is what I care. — Septiadi Agus, May 10 '13 at 09:55

score 1 · Answer 1 · edited Jun 20 '20 at 09:12

Is there any guide here?

Here is a link to Core Data Programming Guide: Object Lifetime Management.

It was updated on July 2014, so it may have new information not published when you asked this question.

By default, though, the references between a managed object and its context are weak. This means that in general you cannot rely on a context to ensure the longevity of a managed object instance, and you cannot rely on the existence of a managed object to ensure the longevity of a context. Put another way, just because you fetched an object doesn’t mean it will stay around.

The exception to this rule is that a managed object context maintains a strong reference to any changed

This means your references to NSManagedObject subclasses (Core Data objects) should be strong.

score 1 · Answer 2 · answered Oct 22 '15 at 01:14

I am currently also unsure whether or not references should be strong or weak. The previous guys stated that they should be strong, but then I found this on:

https://developer.apple.com/library/prerelease/watchos/documentation/Cocoa/Conceptual/CoreData/CoreDataandStoryboards.html#//apple_ref/doc/uid/TP40001075-CH10-SW1

In the example code, Apple does this:

@interface DetailViewController : UIViewController

@property (weak) AAAEmployeeMO *employee;

@end

What we tend to do is to have a strong reference to the primary key of the object, and then a weak property that does lazy initialization if the object is nil. Like this;

@interface MyVC : UIViewController

@property (nonatomic, strong) NSString *objectId; 
@property (nonatomic, weak) SomeObject *myCoolObject; 

@end 

@implementation MyVC 

- (SomeObject *)myCoolObject {
    if (_myCoolObject == nil) {
        _myCoolObject = [SomeObject MR_findFirstByAttribute:@"primaryKey" withValue:self.objectId];
    }
    return _myCoolObject; 
}

I'm still not sure if this is the correct way of doing it though. Please correct me.

In that link, Apple state "When the property is declared as weak it is automatically set to nil when the object is deleted." So many struggle with this e.g. https://stackoverflow.com/questions/4340445/how-can-i-tell-whether-an-nsmanagedobject-has-been-deleted — malhal, Feb 24 '20 at 15:44

Should Reference to Core Data Object be Strong or Weak?

2 Answers2