Ich habe ein ziemlich großes Core Data-basiertes Datenbankschema (~ 20 Entitäten, über 140 Eigenschaften), das große Änderungen durchläuft, während es von unserer 1.x-Codebasis auf unsere 2.x-Codebasis migriert.

Ich bin sehr vertraut mit der Durchführung von Lightweight-Migrationen, bin aber ein bisschen verblüfft über diese spezielle Migration, da es einige Entitäten gibt, die verwandte Objekte als umwandelbare Attribute auf der Entität selbst gespeichert haben, aber jetzt möchte ich diese zu tatsächlichen Entitäten migrieren .

Dies scheint wie einperfekt Beispiel, wenn Sie eine starke Migration anstelle einer leichten Migration verwenden sollten, aber ich bin auch nicht zu glücklich darüber. Ich bin mit starken Migrationen nicht vertraut. Eine der Entitäten mit diesem Array -> Modellierte Beziehungskonvertierung belegt ~ 90% der Zeilen in der Datenbank. Diese Datenbanken sind in der Regel größer als 200 MB, und ich weiß Ein großer Teil unserer Kunden nutzt iPad 1s. Das zusammen mit den wiederholten Warnungen in der Dokumentation von Apple und Marcus Zarras (ausgezeichnetem) Core Data-Buch über die Geschwindigkeit und Speichernutzung einer starken Migration macht mich zu etwas ganz Besonderemsehr vorsichtig und auf der Suche nach einem anderen Weg, um mit dieser Situation umzugehen.

WWDC 2010 "Mastering Core Data" -Sitzung 118 (gleitet hier, erfordert Login, die neuntletzte Folie mit dem Titel "Migration Post-Processing" (Nachbearbeitung der Migration) beschreibt eine Möglichkeit, dies zu umgehen: Führen Sie die Migration durch und verwenden Sie dann die Metadaten des Speichers, um zu kennzeichnen, ob oder Die benutzerdefinierte Nachbearbeitung, die Sie ausführen möchten, wurde nicht abgeschlossen. Ich denke, das könnte der richtige Weg sein, aber es fühlt sich für mich ein bisschen kitschig an (mangels eines besseren Wortes). Außerdem mache ich mir Sorgen, dass Attribute, die in der Praxis veraltet sind, herumhängen. Ex. Wenn ich das Attribut barArray von entity foo in eine Beziehung zwischen entity foo und entity bar verschiebe und barArray nicht auslasse, ist barArray immer noch als Attribut vorhanden, in das geschrieben und von dem gelesen werden kann. Ein möglicher Weg, dies zu lösen, besteht darin, zu signalisieren, dass diese Attribute veraltet sind, indem Sie ihren Namen dahingehend ändern, dass sie "veraltet" sind, und möglicherweise die Accessoren außer Kraft zu setzen, wenn sie verwendet werden. Bei KVO gibt es jedoch keine garantierte Kompilierung -zeitige Lösung, die verhindert, dass Benutzer sie verwenden, und ich lasse "Trap-Code" lieber herum, zumal besagter "Trap-Code" so lange vorhanden sein muss, wie ich möglicherweise Kunden habe, die noch von 1.0 migrieren müssen.

Dies wurde zu einer Art Gehirnmüllkippe, als ich beabsichtigt hatte. Aus Gründen der Klarheit lauten meine Fragen also:
1) Ist eine starke Migration angesichts der Einschränkungen, unter denen ich arbeite, eine besonders schlechte Wahl? (geschäftskritische App, mangelnde Erfahrung mit umfangreichen Migrationen, Datenbanken mit einer Größe von über 200 MB, Zehntausende von Zeilen, Kunden, die ein iPad mit iOS 5+ verwenden)
2) Wenn ja, ist die in Sitzung 118 beschriebene Nachbearbeitungstechnik für die Migration meine beste Wahl?
3) Wenn ja, wie kann ich diese "veralteten" Attribute sofort beseitigen, damit sie meine Codebasis nicht mehr verschmutzen?