I just noticed the link you posted before and see they are suggesting the same thing, so I'll do my best to try and translate so you can understand what you need to do. Let me know if I'm unclear since I'm making metaphoric pictures here.
In your case, you are displaying the value of
hairColor which is a property on the relationship of
looks. When you are displaying the
Woman entity in a row, you are essentially superimposing
hairColor as if it were a property directly on the
Woman entity. We can visualize this superimposition through a computed property, which doesn't have data but gathers it elsewhere via its getter, and in this case is something like:
Code:
var hairColor: UIColor {
get {
self.looks.hairColor
}
}
Now, the issue comes from changing the value of
hairColor. When updated, the entity
Looks is actually the only object that changed, and because that object isn't observed by FRC there are no updates
even though Woman superimposes that variable. The FRC doesn't have a way to be told that any random object change relates to
Woman since
Woman is the object extending the graph outside of the FRCs knowledge.
So,
our goal is to let the graph know that changing the property hairColor on Looks actually affects its children. This can be done two ways depending on how extensive relationships affect their children.
The first and easiest, and the method I would suggest for you, is to write a custom setter on the
Looks entity that the property is changing on, a la:
Code:
var hairColor: UIColor? {
set {
self.willChangeValueForKey("rawHairColor")
self.setPrimitiveValue(ConvertColorForDBStore(newValue), forKey: "rawHairColor")
self.didChangeValueForKey("rawHairColor")
self.willChangeValueForKey("woman") //Notify the graph that the woman relationship will change
self.didChangeValueForKey("woman") //It didn't, BUT it triggers KVO as if it had
}
get {
self.willAccessValueForKey("rawHairColor")
let color = ConvertDBStoreToColor(self.primitiveValueForKey("rawHairColor"))
self.didAccessValueForKey("rawHairColor")
return color
}
}
(Take this as reference, I wrote it on my phone so I'm pretty sure it won't compile :S)
There's a few things to take into consideration, but I believe it will get my point across. First, that I don't override or use property observers - this is because you cannot override NSManaged properties
and it makes the API for normalizing values before storing into the database extremely clean. The magic in this snippet is the KVO that fires on the (one-to-one assumed) relationship - it tells the graph that the relationship property needs to be reevaluated.
In the grand scheme of things, that object on the other side of the
Look relationship is
Woman and it will be marked dirty and therefore be registered by the FRC as needing an update.
I'll hint at the second method but won't go into detail: Instead of having the ManagedObject subclass mark its relationship as dirty, you can have an object subscribe to Notification Center to listen for
NSManagedObjectContextObjectsDidChangeNotification and manually move though the graph to mark the entities which relate to the changed entity as dirty. This makes more sense when dealing with deeper relationship nests and especially when working with self-referencing relationships.
