How does the setter of a Core Date attribute manage memory?

Question

Does a setter of a CoreData-attribute retains? or copies the value or what does the setter? I want to know if I have to (auto-)release the value that I am putting into the setter.

I've done some quick tests on that. Assuming the following model:

+----------+
| Class A  |
+----------+
| v :int32 |
+----------+

The generated ManagedObject then looks like this:

//A.h
@interface A :  NSManagedObject  
{
}
@property (nonatomic, retain) NSNumber * v;
//...

//A.m
@implementation A 
@dynamic v;
...

Ok, the property is marked with retain, so if I set a NSNumber to v the NSNumber should be retained. but it is not (I think). I did the following:

A *a = ... ;
NSNumber *retainCheck = [[NSNumber alloc] initWithInt:23];
NSLog(@"retainCheck1: %i",[retainCheck retainCount]);
a.v = retainCheck;
NSLog(@"retainCheck2: %i",[retainCheck retainCount]);
NSLog(@"retainCheck3: %i",[a.v retainCount]);
NSLog(@"pointer1: %#x",retainCheck);
NSLog(@"pointer2: %#x",a.v);

this produces the following output:

retainCheck1: 1
retainCheck2: 1
retainCheck3: 1
pointer1: 0x62f068
pointer2: 0x62f068

Both NSNumbers are the same NSNumber-instance (same pointer-value -> so it does no copy or sth like that) and the NSNumber doesn't seem to be retained by the setter.

Am I doing sth. wrong in my test? or is the behaviour of NSManagedObject-setters not the same as described in the header?

edit: I am calling retainCount because I wanted to observer a retain not release or autorelease. The observed behaviour can be explained by the flyweight-pattern linked by Abizern

score 6 · Answer 1 · answered May 30 '11 at 19:08

6

You shouldn't care how a Core Data object manages it's memory, just have faith that it will do so properly. Looking at the retain count of an object is rarely useful, as it can change depending on many things in the Cocoa SDK.

All you need to do is make sure that for every time you call alloc, retain, new or copy in your code, it is balanced somewhere with an autorelease or release.

answered May 30 '11 at 19:08

Simon Goldeen

9,080
3
36
45

so I should assume that the setter retains and I should release my NSNumber in this case? – thomas May 30 '11 at 19:12
Yes, since you have `[[NSNumber alloc] initWithInt:23];` in your code, at some point you should release that object. – Simon Goldeen May 30 '11 at 19:19

score 3 · Accepted Answer · answered May 30 '11 at 19:14

3

Firstly - Don't worry about how Core Data manages it's properties - As long as you release the objects that you own, that's what matters.

Secondly - you're testing using NSNumber. NSNumber is a strange class that adopts the flyweight design pattern, so getting the retainCount of an NSNumber isn't going to tell you anything about how Core Data manages its objects.

answered May 30 '11 at 19:14

Abizern

146,289
39
203
257

1

Finally, **Do not call retainCount**. It is useless. – bbum May 31 '11 at 17:00
1

Oh yeah, I knew I forgot to mention the [appropriate time](http://stackoverflow.com/questions/4636146/when-to-use-retaincount/4636157#4636157) to use retainCount. – Abizern May 31 '11 at 17:48

octy · Answer 3 · 2011-05-30T20:19:31.600

From the Core Data Programming Guide:

In addition to always being nonatomic, dynamic properties only honor retain or copy attributes—assign is treated as retain. You should use copy sparingly as it increases overhead. You cannot use copy for relationships because NSManagedObject does not adopt the NSCopying protocol, and it's irrelevant to the behavior of to-many relationships.

The Core Data @dynamic accessors always retain properties on assignment.

As for the retainCount, don't look at it like that (as @Abizern and @Simon Goldeen already mentioned). The iOS frameworks deal with it in their own way to ensure that the memory management rules hold.

How does the setter of a Core Date attribute manage memory?

3 Answers3