Ich bin mir nicht sicher, ob das ein Problem mit der Art und Weise ist, wie Magical Record speichert, oder ich mache nur einen Noob-Fehler irgendwo.
Ich verwende einen NSFetchedResultController (FRC) und UITableView, um eine Liste von Entitäten anzuzeigen, wenn der Benutzer auf "Hinzufügen" tippt, wird ein neuer View Controller mit einem Editor gedrückt, eine neue Entität wird mit [MyEntity MR_createEntity] erstellt. Der Benutzer kann hier zusätzliche Entitäten hinzufügen, die über eine Beziehung zur Haupteinheit hinzugefügt werden. Wenn der Benutzer in diesem View-Controller auf "Speichern" klickt, wird der Kontext mit [[NSManagedObjectContext MR_contextForCurrentThread] MR_save]
Der NSFetchedResultsController scheint zu aktualisieren, aber wenn ich tippe, um die Entity zu bearbeiten, ist keine der untergeordneten Entitäten vorhanden. Das Debugging scheint zu zeigen, dass die FRC trotz der Speicherung der Entity immer noch die Entität mit ihrer temporären ID besitzt.
Ich mache eine naive [self.tableView reloadData] in der FRC controllerDidChangeContent Delegate Methode.
Beim Neustart der Anwendung werden die korrekten Entitäten geladen, und die untergeordneten Entitäten werden im Editor-Ansichtscontroller ordnungsgemäß angezeigt.
Es sieht so aus, als ob der FRC auf das Speicherereignis "main thread" reagiert, aber das Speichern findet tatsächlich auf einem Hintergrundthread statt, so dass der FRC es nicht sieht. Ich habe überprüft und alle "meine" Operationen (Einrichten der FRC, Erstellen und Holen von Entitäten) geschehen alle im Hauptthread-Kontext.
Ich habe versucht, auf MR_rootSavingContext auf Änderungsbenachrichtigungen zu warten und sie mit dem Hauptthreadkontext zusammenzuführen, welche Art von funktioniert, aber ich endete mit doppelten Zeilen in der FRC (eine war die richtige "permanente" Entität und eine war die temporäre) .
OK, ich bin mir nicht sicher, ob dies "der richtige Weg" ist, aber ich habe festgestellt, dass es korrekt funktioniert, wenn ich NSFetchedResultsController im MR_rootSavingContext anstelle des Standardkontexts mit der "inContext" -Version von MR_fetchAllSortedBy .
Ich denke, das macht Sinn aus der Sicht, dass der FRC jetzt den rootSavingContext statt eines seiner Kinder beobachtet. Trotzdem hätte ich gedacht, da ich alle meine Operationen auf dem gleichen Thread mache, der kein Problem wäre.
Update: Das einzige Problem bei diesem Ansatz ist, dass wenn ich einfach die Entity mit [frc objectAtIndexPath:] schnappe, um sie dem Bearbeitungsansicht-Controller zu geben, dann ist sie nicht mehr im Standardkontext. Umgangen wurde dies, indem die Entität im Standardkontext mithilfe von existingObjectWithID von NSManagedObjectContext erneut abgerufen wurde. Es fühlt sich immer noch nicht ganz richtig an, aber es funktioniert für mich.
Ich bin mir bewusst, dass dies eine alte Antwort ist, aber nichts von dem oben genannten funktionierte für mich und wird hoffentlich zukünftigen Lesern helfen
Bei mir wurde das Problem dadurch verursacht, dass ich versucht habe, einen rein lokalen Speicher einzurichten, der eine SQLite-Datei verwendet, die zuvor mit iCloud verwendet wurde.
Im Grunde habe ich versucht, iCloud mit meiner CoreData-App zu implementieren, habe die grundlegenden Schritte zur Einrichtung mit einem Ubiquity-Container usw. gemacht, aber dann wegen der damit verbundenen inhärenten Instabilität zurückgekehrt (warum CoreData und iCloud STILL nicht tun) verstehst du ?!), aber Kakao mag es nicht, dass du so zurückläufst.
Glücklicherweise habe ich das nicht in einer Live-App gemacht, daher ist es relativ einfach zu ändern, da es nur Entwicklungsgeräte betrifft. Wenn Sie jedoch von iCloud zu einem lokalen Geschäft in einer Live-App wechseln, denke ich Sie müssen möglicherweise eine dieser Lösungen auschecken:
Tags und Links objective-c core-data magicalrecord nsfetchedresultscontroller