How can I detect changes to a specific attribute of an NSManagedObject
? In my Core Data data model, I have a Product
entity that represents a product for sale. The Product
entity has several attributes: price
, sku
, weight
, numberInStock
, etc. Whenever the price
attribute of a Product
changes, I need to perform a lengthy calculation. Consequently, I would like to know when the price
attribute of any Product
changes, [edit] even if that change comes from merging a context saved on another thread. What is a good way to go about doing this? I have thousands of Product
objects in my store; obviously it's not feasible to send each one an addObserver
message.
I have been using NSManagedObjectContextObjectsDidChangeNotification
to detect changes, but it only notifies me that a managed object has changed, not which attribute of that object has changed. I could redo the calculation whenever there's any change to a Product
, but that results in useless recalculations whenever an irrelevant attribute has changed. I'm considering making a Price
entity (that only contains a price
attribute) and using a to-one relationship between Product
and Price
. This way, I can detect changes to Price
objects in order to kick off the calculation. This seems excessively kludgy to me. Is there a better way?
Update:
@railwayparade pointed out that I could use the changedValues
method of NSManagedObject
to determine which properties have changed for each updated object. I completely missed that method, and it would totally solve my problem if the changes weren't being made on a background thread and merged into the main thread's context. (See next paragraph.)
I completely missed a subtlety about the way that NSManagedObjectContextObjectsDidChangeNotification
works. As far as I can tell, when a managed object context saved on another thread is merged into a context on the main thread (using a mergeChangesFromContextDidSaveNotification:
), the resulting NSManagedObjectContextObjectsDidChangeNotification
only contains change information about objects that are currently in the main thread's managed object context. If a changed object isn't in the main thread's context, it won't be part of the notification. It makes sense, but wasn't what I was anticipating. Therefore, my thought of using a to-one relationship instead of an attribute in order to get more detailed change information actually requires examination of the background thread's NSManagedObjectContextDidSaveNotification
, not the main thread's NSManagedObjectContextObjectsDidChangeNotification
. Of course, it would be much smarter to simply use the changedValues
method of NSManagedObject
as @railwayparade helpfully pointed out. However, I'm still left with the problem that the change notification from the merge on the main thread won't necessarily contain all of the changes made on the background thread.
One point with regard to this thread,
The NSManagedObjectContextObjectsDidChangeNotification generated by Core Data indicates that a managed object has changed, but doesn't indicate which attribute has changed.
It actually does. The "changedValues" method can be used to query which attributes changed.
Something like,
if([updatedObjects containsKindOfClass:[Config class]]){ //if the config.timeInterval changed NSManagedObject *obj = [updatedObjects anyObject]; NSDictionary *dict=[obj changedValues]; NSLog(@"%@",dict); if([dict objectForKey:@"timeInterval"]!=nil){ [self renderTimers]; } }
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