0
votes

I found really strange problem using CoreData and NSFetchedResultController.

I'm showing in a UITableView (using NSFetchedResultController) elements returned from this predicate:

NSPredicate *activeFilterPredicate = [NSPredicate predicateWithFormat:@"(SUBQUERY(properties, $x, ($x.type == %@) AND ($x.deleted == %@)).@count > 0)", @"sales/lead", [NSNumber numberWithBool:NO]];

It works fine when I reload elements manually or if I'm modifying them on same NSManagedObjectContext. My app also updates itself from web server - than on child thread I'm modifying it and saving through parent-child relation.

All methods from NSFetchedResultsController delegate works correctly - for other NSPredicates I have there everything works fine.

After 1 day of analyzing and trying to nail down the problem it seems the problem is within this part:

($x.deleted == %@).

It seems that when it gets modified by child context, NSPredicate of parent context is not working correctly and not filtering out the entries that it should.

When I switch property to NSString instead of NSNumber and I encoded YES/NO into NSString - it worked.

Did anyone have this problem and now how to overcome it ? I would like to switch to using BOOL properties at the end.

I already tried with (deleted == NO) - doesn't help

1
Duplicate of Core Data boolean key value change not reflected in fetch ? - You should not call a relationship "deleted". - Martin R

1 Answers

0
votes

Fetch results controllers with relationship predicates are a big problem. I've seen this also in our own app. I have a bug report open for this issue from Jul 03 (rdar://14373992) but it's open.

As a workaround, we ended up denormalizing the data a little, and basically update a property on the main object with each change to the relationship. This is a better solution in the long run anyway, since accessing that property in the fetch results controller is much more performant than iterating relationships per objects.