Nicht genügend Arbeitsspeicher bei der Kerndatenmigration

Question

Ich migriere ein CoreData-Modell zwischen zwei Versionen einer Anwendung. Ich habe binäre Daten als Blobs in der vorherigen Version gespeichert, und ich möchte sie aus den Blobs für die Leistung entfernen. Mein Problem ist, dass während der Migration anscheinend Core Data alles in den Speicher lädt, was zu Warnungen bei niedrigem Speicher führt und dann dazu führt, dass meine App getötet wird.

Apple-Dokumentation schlägt vor, die folgenden: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmCustomizingTheProcess.html#//apple_ref/doc/uid/TP40005510-SW9

Es scheint jedoch, auf die Tatsache zu stützen, dass die großen Objekte unterschiedliche Mapping angewendet werden. In meinem Fall sind alle Objekte im Grunde die gleichen und die gleiche Zuordnung muss auf jeden von ihnen angewendet werden. Ich sehe in diesem Fall nicht, wie ich ihre Technik anwenden könnte.

Wie sollte ich eine Migration mit sehr großen Objekten behandeln?

Answer 1

Ich vermute, dass Sie eine Reihe von Änderungen haben, die Sie zusätzlich zu den Daten aus Blobs ziehen möchten. Mein Vorschlag ist, die Migration in ein paar Stufen durchzuführen. Ich denke hier irgendwie laut nach, also könnte es möglich sein, das zu verbessern. Dies erfordert, dass Sie SQLite verwenden.

Um diese Arbeit zu machen, können Sie drei Versionen des Modells haben werden:

1. Das ursprüngliche Modell
2. Das Modell mit dem Attribut entfernt (und möglicherweise mit einer speziellen einzigartigen ID added-- siehe unten)
3. Das Modell mit all den Änderungen, die Sie vorgenommen haben, einschließlich der Zugabe des neuen Unternehmens und die Beziehungen ersetzt das Attribut

der Grund, dies zu tun, ist, dass die tra Version von Version 1 bis 2 sollte mit einer automatischen Lightweight-Migration möglich sein. In diesem Fall muss Core Data nichts in den Speicher laden - es werden nur SQL-Anweisungen ausgegeben, um die Änderungen direkt in der Datenbank vorzunehmen.

Sie beginnen also mit der Einrichtung Ihres persistenten Geschäftskoordinators mit der alten Modellversion. Nachdem Sie die Daten geladen haben, durchlaufen Sie alle Objekte, die Sie migrieren, extrahieren Sie das Binärattribut und schreiben Sie es irgendwie auf den Datenträger. Sie können eine Abrufanforderung mit Batch-Entleerung und regelmäßigem Autorelease-Pool-Entleeren verwenden, um sicherzustellen, dass nicht zu viel Speicher für temporäre Objekte belegt wird. Speichern Sie die Daten in dem Verzeichnis, das Sie mit NSCachesDirectory erhalten. Sie möchten die Daten natürlich so speichern, dass Sie sie wieder mit der verwalteteObjektID des Objekts verknüpfen können.

Dann schließen Sie alles und bitten Core Data, den Speicher von Version 1 auf Version 2 zu migrieren. Weitere Informationen finden Sie unter this link. Öffnen Sie den Laden mit Version 2.

Sie müssen möglicherweise einen Schritt hinzufügen, wo Sie jedem Objekt eine eindeutige ID zuweisen, da ich nicht sicher bin, ob Core Data Objekt-IDs beibehält, wenn es nicht leicht ist Migration. Wenn Sie dies tun müssen, würde Ihr Modell der Version 2 dem Objekt, dem Sie die Binärdaten entnehmen, ein neues Attribut hinzufügen, das entweder optional ist oder einen Standardwert hat. Da die einfache Migration die managedObjectIDs nicht ändern sollte, können Sie die Zuordnung Ihrer neuen eindeutigen ID zu den managedObjectIDs speichern, die Sie zusammen mit den binären Daten vor zwei Absätzen gespeichert haben.

Speichern Sie die Daten und schließen Sie das Geschäft.

Öffnen Sie den Store und führen Sie eine Migration von Version 2 zu Version 3 durch, die eigentlich der Code sein sollte, den Sie bereits geschrieben haben, bevor Sie die Frage gepostet haben. Sobald der Shop geöffnet ist, fügen Sie alle Objekte hinzu, die Sie im Store der Version 1 gespeichert haben, und richten Sie die Beziehungen mit den Daten ein, die Sie auf dem Weg gespeichert haben.

Einfach, oder?