Das ist ziemlich lustig. In meiner Anwendung erstelle ich Tausende Einträge in der Datenbank (in einem anderen Thread verwende ich MagicalRecord). Alles scheint gut zu funktionieren (aus dem Hintergrund / Vordergrund / Kontext).
Wenn ich im Haupt-Thread versuche, die "gerade eingefügten" Daten zu holen, habe ich folgendes Verhalten entdeckt:
%Vor%Nun, was ich bekomme ist:
Family -Objekte wie erwartet Beim Debuggen der SQL-Anweisung bekomme ich Folgendes:
Die "erste" Aussage:
CoreData: Annotation: Ausführungszeit des gesamten Abrufs: 0.0000s für 0 Zeilen.
Die "zweite" Aussage ":
CoreData: sql: SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZNAME, t0.ZCOMPANY VON ZFAMILY t0 JOIN ZCOMPANY t1 ON t0.ZCOMPANY = t1.Z_PK WO t1.ZNAME =? ORDER BY t0.ZNAME
CoreData: Annotation: sql Verbindung Abrufzeit: 0,0005s
CoreData: Annotation: Ausführungszeit des gesamten Abrufs: 0,0007s für 2 Zeilen.
Die "dritte" Aussage:
CoreData: Annotation: Ausführungszeit des gesamten Abrufs: 0.0000s für 0 Zeilen.
Die urkomische Sache ist, dass ich die Anwendung schließe (ich meine, wirklich manuell zu beenden) und und ich öffne es zurück, funktionieren alle drei "holen" -Aussagen.
Warum scheinen die erste und die dritte fetch-Anweisung nie ausgeführt zu werden? Wie kann man das Problem untersuchen?
Ich hatte das gleiche Problem, das habe ich herausgefunden und wie ich es gelöst habe.
Magischer Datensatz hat ein root NSManagedObjectContext als übergeordnetes Element des Standard NSManagedObjectContext . Wenn ich ein NSFetchedResultsController im Standardkontext erstelle, scheint alles in Ordnung zu sein, genau wie du.
Das Problem ist, dass alle neuen NSManagedObject 's mit ihren immer noch temporären ObjectID ' s zurückkommen. In meinem Fall verwendete ich also NSPredicate , um eine Abfrage auf eine zugeordnete Tabelle zu legen. Ich habe nicht nur die Assoziationsmethode aufgerufen, weil ich alles in den Speicher laden wollte und wollte, dass NSFetchedResultsController für mich Änderungen übernimmt.
Mit der temporären ObjectID findet die Abfrage null Ergebnisse und genau das wird angezeigt.
Offenbar profitiert der untergeordnete Kontext (Standard) nicht von der Umwandlung in nicht temporäre IDs, obwohl er im Backing Store beibehalten wurde.
Noch schlimmer war es, als ich versuchte, das Problem mit obtainPermanentIDsForObjects:error: zu erzwingen. Core Data beschwerte sich, dass es einen Fehler für meine Instanz nicht beheben konnte. Es gibt keine Möglichkeit, dass es tatsächlich eine Schuld war. Das bloße Auffrischen des Objekts hatte keine Wirkung. Ich vermute, das ist ein Core Data Bug, den kaum jemand kitzelt, weil er einfach die Assoziationsmethoden benutzt, um ein NSSet zu bekommen.
Mein Fix war, den Elternkontext für NSFetchedResultsController zu verwenden, genau wie in dieser Frage, Magical Record, Speichern und NSFetchedResultsController .
Ich habe bereits den Standard in einen neuen untergeordneten Kontext beim Bearbeiten eingefügt und daher die Instanzen in diesen Bearbeitungskontext mit createInContext kopiert, so dass ich keine zusätzliche Arbeit mehr leisten musste, als nur .parentContext hinzuzufügen das Argument.
Das ist übrigens nur bei neuen Instanzen der Quelle der Assoziation passiert. Sobald eine Instanz vom Start an vorhanden war, hatte sie eine nicht temporäre ObjectID und hatte das Problem nie.
Tags und Links nspredicate sqlite ios core-data magicalrecord