I have 2 NSFectchedResultsController for 2 Entities which populates the tableView fine.
If I remove an object, it is removed fine.
If I add an object to the first NSFectchedResultsController, it works fine, but does not work fine with the second NSFectchedResultsController.
The object is being added NSManagedContext in the background thread for both entities. The are being updated deleted and inserted on the same background thread for both entities.
So I am really confused to why the insert/update don't work on the second NSFetchController.
thanks for your help
Each FRC will have a fetch request set to a single entity. The FRC will respond only to changes that affect its particular entity and then only if you have the FRC delegate properly configured.
You need to make sure that the managed object context used by the second FRC (if different from the one used by first FRC) receives the merge notifications from the background thread.
Related
I have a NSFetchedResultsController tied to my main managed object context. It is in charge of keeping data for a table view in my main view.
I have an NSOperation running on a background thread that refreshes/deletes the managed objects that the fetched results controller is keeping track of. I create a child context (private concurrency type / parent = main managed object context) in the nsoperation and insert/delete objects. When it is finished, it saves its context, as well as the parent context.
What's interesting and very frustrating is that this works fine in iOS 6. When I insert or delete objects, my fetched results controller is notified of the changes and everything works as expected. However, on iOS 5, everything works except for deletes. The fetched results controller is not notified of a delete. However... if I manually refresh the fetched results controller (making it nil and refetching the same predicate) then it will show the expected result.
Also, when I register for change/save notifications on the main context, I can see that the user info dictionary contains the objects that I've deleted... even in iOS 5!
One issue that I thought it may be, but I don't think holds because I've removed the factors, is that this object is in a many to one relationship with another object. The object I am deleting/inserting is an "employee" and it has a relationship with a "department". The employee is set to nullify and the department is set to cascade.
As I said, this works fine in iOS6 but not in iOS5.
Any tips would be very helpful.
This bug is due to saving to the persistent store. This child context saves itself, then calls perform block on it's parent, the main managed object context. When the main managed object context saves, it triggers a background context to write to the persistent store. When I removed the background context save, the fetched results controller updated as expected.
Something interesting that I found that was probably causing this was that the managed object was leaking every time I tried saving to the store. Not exactly sure how to fix this yet, but it's good to know the reason for it.
I'm losing my mind around this question.
So I have a Core Data setup in my iOS app done this way:
http://www.cocoanetics.com/2012/07/multi-context-coredata/
I then insert an object by creating a temporary MOC (as explained in the blog post) and perform saves on all 3 contexts in performBlock: methods.
In a view controller I have an NSFetchedResultsController and it gets notified that I did indeed insert a new object. The problem is that the NSFetchedResultsChangeInsert is fired twice and each time the object that is passed trough has a different objectID (it also is a different object instance in memory). What happens is that I then have 2 rows inserted in my table view but un the SQL database there is only one new. It then of course crashes when I scroll to the bottom of the table view.
If I also perform some updates on the object I get NSFetchedResultsChangeUpdate called only once and with the objectID that was passed in the second NSFetchedResultsChangeInsert call.
The first ID looks like this:
<x-coredata:///ReceivedMessage/t605BB9A7-A04E-4B89-B568-65B12E8C259A2>
The second (and all consequent ones) like this:
<x-coredata://02A917C5-850F-4C67-B8E4-1C5790CF3919/ReceivedMessage/p28>
What could this be? Am I missing out something obvious?
PS: I also checked if the notification comes from the same context, thread, etc. It does.
The two IDs you are seeing may very well represent one object. The difference between them is just that the first one is a temporary object ID, assigned to the object on creation, and the second one is the permanent object ID, assigned to the object when it gets stored to the managed object store (see NSManagedObjectID's isTemporaryID).
To work around this issue you could call NSManagedObjectContext's obtainPermanentIDsForObjects:error: just before you save the temporary MOC. This way the inserted object will have just one ID during the save propagation and the NSFetchedResultsControllerDelegate methods should get called just once.
I am trying to fetch 10000records from CoreData in a UITableView using NSFetchedResultsController and trying to make it as fast as possible (since the request has a sort descriptor it takes longer to fetch this amount of data).
I am trying to fetch 100records from CoreData with the first and main NSFetchedResultsController(used in the delegate methods of the table), that is displayed on the table while in another queue I started in viewDidAppear another fetch for all 10000records on an auxiliarFRC. After the fetch in the AuxFRC ends, I assign to the main FRC the AuxFRC so all the records get transfered and I reload the table.
My problem is that the UITableView gets stuck at the first loaded rows till the AuxFRC ends the fetch even if I dispatch the performFetch, and I can not understand why this happens, or if this way is wrong what other way can be used to fetch 10000records and stay up to date if the data changes?
I guess the problem was the NSManagedObjectContext - that is not thread safe and I used the same one for both the fetches. I created a copy of the original one and changed the AuxFRC on the second context. This solved everything.
The trick is to use the cache mechanism of FRC and coordinate the asynchronous fetch with the display thread.
All is summarised in this answer.
My program does work like link below:
Update results of NSFetchedResultsController without a new fetch
show result of NSFetchedResultsController to UITableView
get new object from web service and store it to core data (in same view controller, with RestKit)
update table view with notification of NSFetchedResultsController delegate
The implementation of NSFetchedResultsControllerDelegate is copied from Apple's Core Data project and my predicated is:
[NSPredicate predicateWithFormat:#"isMyTest == TRUE"]
If the property update goes from TRUE to FALSE, it removes rows from the tableview (because the object for the row is in fetchedObjects of the NSFetchedResultsController)
However, if the property update goes from FALSE to TRUE, the NSFetchedResultsController notifies nothing, so the new data cannot be seen in table view. If I update BOTH NSFetchedResulsController and UITableView manually, it shows the new data.
I thought NSFetchedResultController watches all changes in persistent store, is it too big hope? :D
(I really want to do that because other view controller can update persistent store, then it is hard to update the view controller.)
If so, can you let me know how can I update NSFetchedResultsController in beautifully way?
(update)
in reference of NSfetchedResultsController, I read words below:
A controller thus effectively has three modes of operation, determined
by whether it has a delegate and whether the cache file name is set.
No tracking: the delegate is set to nil. The controller simply
provides access to the data as it was when the fetch was executed.
Memory-only tracking: the delegate is non-nil and the file cache name
is set to nil. The controller monitors objects in its result set and
updates section and ordering information in response to relevant
changes.
Full persistent tracking: the delegate and the file cache name are
non-nil. The controller monitors objects in its result set and updates
section and ordering information in response to relevant changes. The
controller maintains a persistent cache of the results of its
computation.
"Full persistent tracking" does not mean what I want? I set up cacheName, but it works same.
I thought NSFetchedResultController watches all changes in persistent
store, is it too big hope?
The FRC only automatically observes the objects returned by its fetch. This is normally not a problem as changes to objects monitored by an FRC should arise from either the tableview UI or a background context. In the former, the FRC is alerted to the change and in the latter, merging the foreground and background context will trigger the FRC to update.
It sounds like you've got code changing values but you're not notifying the FRC that you've made any changes. (If you got a tableview displaying all objects whose isMyTest == TRUE then obviously you can't access objects from the UI whose isMyTest == FALSE.) In that case, you need to register the tableview controller for:
NSManagedObjectContextObjectsDidChangeNotification
… notifications from the context so that you can tell the FRC to update for changes made outside its observation.
I'm sorry to my mistake, I tested with new test project.
CoreData DOES full-tracking of whole persistent store.
This means, if new object that is suitable to predicate of NSFetchedResultsController, delegate will notify it.
I have a TableViewController that's a NSFetchedResultsControllerDelegate. The data that this table is displaying is getting updated in another context (by RestKit) and getting merged upon notification. At this point if I were to run a query on the main thread's ManagedObjectContext I see the data that was updated by the other thread.
When that merge of context happens, the TableViewController, being a NSFetchedResultsControllerDelegate, even gets the controller:didChangeObject:atIndexPath:forChangeType:newIndexPath message. The issue I'm having is that the object (didChangeObject), still has the old data. I imagine this is so because whatever is calling this message just uses the current NSFetchResultsController to give me that object.
Why didn't the NSFetchResultsController's fetchObjects get updated from the context merge? Is there a way to have fetchObjects be updated by the context merge and perform this fetch again?
The answer was that the merge from changes marks the NSManagedObject's data as being in fault because it's stale. By default staleness interval is set to be infinite apparently. I would give credit to where I found this info but I can't find it now. Anyway, setting the NSManageObjectContext like so allows that context to see the updated info right away.
[__managedObjectContext setStalenessInterval:0];