Take the 2-minute tour ×

I have a project using CoreData. I use Mogenerator to generate the subclasses.

When I set the value of a property, this value isn't actually assigned. Each subsequent time I try to set the value, the previous value I set it to was not assigned.

This worked fine as my underlying data framework was Mantle, but since moving to CoreData, this stopped working. I rely on KVO to keep some UIView objects up-to-date with the model.

Again, the ivars of a CoreData NSManagedObject subclass do not seem to take the values I assign them.

Consider the following interface:

@interface Light : _Light{}

 Light / Color Properties
@property (nonatomic, assign) CGFloat brightness; // 0...1
@property (nonatomic, assign) CGFloat hue;  // 0...1
@property (nonatomic, assign) CGFloat saturation;  // 0...1
@property (nonatomic, assign, getter = isEnabled) BOOL enabled;

@property (nonatomic, readonly) UIColor *color;  // derived from the above 

- (void)setHue:(CGFloat)hue saturation:(CGFloat)saturation;  // it often makes sense to set these together to generate fewer KVO on the color property.

and the following .m file:

@interface Light ()
    CGFloat _hue, _saturation, _brightness;

    UIColor *_color;  
@property (nonatomic, assign) BOOL suppressColorKVO;
@property (nonatomic, readwrite) UIColor *color;

@implementation Light

@synthesize suppressColorKVO = _suppressColorKVO;

    BOOL dirty = NO;
    if (saturation != _saturation) {
        // clamp its value
        [self willChangeValueForKey:@"saturation"];
        _saturation = MIN(MAX(saturation, 0.0f), 1.0f);
        [self didChangeValueForKey:@"saturation"];
        dirty = YES;
    if (hue != _hue) {
        [self willChangeValueForKey:@"hue"];
        _hue = MIN(MAX(hue, 0.0f), 1.0f);
        [self didChangeValueForKey:@"hue"];
        dirty = YES;
    if (dirty) {
        if (!_suppressColorKVO) {
            [self setColor: self.color];

// other stuff... the color accessors are also custom.  Derived from the h, s, b values.


I assume I'm not playing nice with CoreData, but I have no idea what's wrong. These hue, saturation, brightness are all 'transient' (not in the core data sense) because they are constantly updated by some hardware we are interfacing with so there's no need to save their state.

share|improve this question
What does '[self setColor:self.color]' ? That looks strange, have you overwritten the color getter method? –  Volker Feb 2 at 21:22
yeah don't worry about that. ;-) Both are custom and I did that because color is derived, and setColor so it would send KVO. That's not the problem. It works just fine. It's the ivars that aren't keeping the value I set on them. –  horseshoe7 Feb 3 at 7:49

2 Answers 2

If hue and saturation are properties in your model then you should be setting their values using setPrimitiveValue:forKey: (or the associated generated primitive methods).

That said, your code all looks custom as model attributes would be NSNumber instances and mogenerator would create value methods for you. So I'm going to guess that these attributes you have aren't backed in the model and that's why they aren't being stored.

So, add the attributes to the model and access the values using the appropriate methods.

share|improve this answer
I will do that later today when I get to it. Not being a CoreData expert at all, are you saying that keeping my own ivars "outside of a CoreData model" (i.e. not declared, and managed by my own accessors, as if it were a direct subclass of NSObject) will not work ? I would have preferred to do it that way as they are really so temporary I thought to just leave CoreData out of it. –  horseshoe7 Feb 3 at 7:51
That isn't how a managed object is designed. If you want to do that you should be using a plain object. –  Wain Feb 3 at 8:15
Can't use a plain object. At any rate, in an effort to really track down the source of this problem, I took this problem behaviour, isolated it from the rest of my app's functionality, put it into a test / sandbox project, and noticed I'm not seeing that problem anymore. So I'm guessing the problem I describe above isn't the whole picture. I will update when I track down the source of the problem. –  horseshoe7 Feb 3 at 9:55
up vote 0 down vote accepted

In the end it had nothing to do with CoreData. This approach above DOES work with CoreData objects. You can have in a subclass some "transient" properties that exist outside of the CoreData NSManagedObject and you can create your own ivars for them, and your own accessors, and it cooperates.

In relation to this question, I have a complex system that also sends some commands to some hardware, and the hardware returns a response whether it accepted the command with the current status. It turns out I had a bug in that handler which was setting these values back to some unexpected value.

What helped me debug it were using watchpoints in the debugger. Really handy feature! You set a watchpoint and it will break in the debugger whenever the memory address of your variable is set with a new value. (A tiny bit more on that here)

share|improve this answer

Your Answer


