This is the code, I save the model via Magical Record:
MagicalRecord.saveWithBlock({ (localContext) -> Void in
var localNotification = CDNotification.MR_findFirstByAttribute("notificationID", withValue: notification.notificationID, inContext: localContext) as CDNotification
localNotification.readNumber = NSNumber(bool: true)
})
Delete is called instead of update after the code above is called:
func controller(controller: NSFetchedResultsController, didChangeObject object: AnyObject, atIndexPath indexPath: NSIndexPath, forChangeType type: NSFetchedResultsChangeType, newIndexPath: NSIndexPath) {
switch type {
case NSFetchedResultsChangeType.Insert:
self.tableView.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade)
case NSFetchedResultsChangeType.Update:
if let cell = self.tableView.cellForRowAtIndexPath(indexPath){
self.configureCell(cell as TableViewCell, atIndexPath: indexPath, withNotification: object as CDNotification)
}
self.tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
case NSFetchedResultsChangeType.Move:
self.tableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
self.tableView.insertRowsAtIndexPaths([newIndexPath], withRowAnimation: .Fade)
case NSFetchedResultsChangeType.Delete:
self.tableView.deleteRowsAtIndexPaths([indexPath], withRowAnimation: .Fade)
default:
return
}
}
This only happens if I set the predicate for fetch request, in example:
fetchRequest.predicate = NSPredicate(format:"user == john")
What is happening here is that instead of the NSFetchedResultsChangeUpdate
change event you expect, you are getting a NSFetchedResultsChangeDelete
followed by NSFetchedResultsChangeInsert
. You may also see a NSFetchedResultsChangeMove
with the same indexPath as source and destination. This is a known issue in several beta versions of iOS 9 22380191 and others.
I know, late answer, but maybe helpful. I had the same problem with iOS 11.3 and Xcode 9.3 and it was driving me mad. The solution was to provide the correct data type in the arguments array for the predicate. After changing it from string interpolation to the actual expected type (NSNumber
in that particular case), the correct NSFetchedResultsChangeType
was Update
instead of Delete
.
I chose string interpolation, because the data type (Bool
in that particular case), was used as scalar type in the Core Data model and NSPredicate
accepted the scalar type during compilation, but raised an runtime exception. Changing it to string interpolation fixed the runtime error and the predicate worked as expected, except the wrong NSFetchedResultsChangeType
was called.
So it seems the bug in Core Data still exists or maybe this was intended to force the correct data type usage.
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