NSFetchedResultsController with predicate based on dependent property

Question

I have a Core Data iPhone app that displays Subscription entities where any of its items are not read. In other words, I construct a predicate like this:

[NSPredicate predicateWithFormat:@"ANY items.read == NO"]

While this works for the initial fetch, it doesn't affect Subscription entities when I modify an Item, so the NSFetchedResultsController never reevaluates the Subscription entities. What would be a better way of structuring this so that the Subscription entity will be updated whenever an item's read property is set?

I did try creating a property unreadCount on Subscription and using keyPathsForValuesAffectingUnreadCount to return a set containing items.read. I didn't expect this to work, and it didn't. I get an exception from _NSFaultingMutableSet telling me that the read key is not supported.

Answer 1

Sorry, I should have read the question closer.

I've worked around a very similar situation by setting the NSFetchedResultsController cache and then refreshing my UITableView in the viewDidAppear: method. I had a pretty small dataset and there was no noticeable performance penalty for frequently refreshing the data.

Answer 2

I see two solutions:

1. When you modify an item have the fetched results controller perform the fetch again and reload the table view.
2. Add a property to Subscription (such as your unreadCount or a boolean hasUnreadItems) and keep it properly updated. Use this property in your fetched results controller.

You can get the set of unread items for a Subscription named "aSubscription" like this:

NSPredicate *pred = [NSPredicate predicateWithFormat:@"read == NO"];
NSSet *unreadItems = [aSubscription.items filteredSetUsingPredicate:pred];

Answer 3

You've encountered a bug with NSFetchedResultsController where notifications are not received (or evaluated?) for the property changes of the related entity.

In this case, the read property of items is not being "watched" for changes.

Rather than re-structuring, you can workaround the problem by faking the change of the items in the relationship. i.e. When you change item.read, also pretend to change item.

My experience only goes as far as a one-to-one relationship. I'm not clear on how you would handle your one-to-many relationship, when you're only changing a single key of one of the many. This may work:

thisItem.read = [NSNumber numberWithBool:NO];
[thisItem.subscription willChangeValueForKey:@"items"];
[thisItem.subscription didChangeValueForKey:@"items"];

That should send a notification that a relationship (subscription.items) is changing on the subscriptions objects being watched by the NSFetchedResultsController.

I can provide a working example of a one-to-one relationship case that works perfectly.