Nachdem ich meiner App eine neue Core Data-Modellversion hinzugefügt hatte, führte ich scheinbar erfolgreich eine Lightweight-Migration durch. Die umgelagerte Datei wurde ordnungsgemäß geladen, aber beim ersten Versuch, über eine bestimmte Beziehung auf ein Attribut zuzugreifen, stürzt die App mit einem abNSRangeException: '*** -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds [0 .. 35]'. Diese Beziehung hat vor der Migration einwandfrei funktioniert. Ich weiß aus anderen Beiträgen hier, dass 4294967295 wirklich ist-1Das einzige, was ich mit 36 ​​Elementen in meiner App / meinen Daten identifizieren kann, ist, dass das Datenmodell insgesamt 36 Entitäten enthält (als Referenz enthält die Beziehung, die abgerufen wird, 58 Elemente in ihrer Tabelle).

Die Frage:

Meine Frage lautet: Gibt es basierend auf dem Fehler, den ich erhalte, und der Fehlerbehebung, die ich unten durchgeführt habe, eine Art Schemaänderung, die die Lightweight-Migration bestehen könnte, aber die Daten auf dem Weg verfälscht, was zu der festgestellten Ausnahme führt? Ich werde versuchen, die Migration auf mehrere Versionen zu verteilen, um das Problem zu isolieren oder zu vermeiden, aber es wäre schön, wenn ich mich auf bestimmte Schemaänderungen konzentrieren könnte, die möglicherweise fehlerhaft sind.

Der Fehlschlag:

Der Fehler tritt mit dem folgenden Code in "myobject" auf:

[[self object2] text];

Die Objekt2-Beziehung ist eins, in beiden Richtungen nicht optional, und weder die Vorwärts- noch die Rückwärtsbeziehung wurde zwischen Datenmodellen geändert. Dastext Attribut ist wahrscheinlich nicht relevant, weil, wenn der Fehler auftritt,awakeFromFetch wird in object2 nicht erreicht. Wenn ich vergeben[self object2] In einer Variablen vor der obigen Anweisung ist die Zuweisung erfolgreich und wird gemeldetdata: <fault>.

Die Datenbank:

Wenn ich die Datenbank in sqlite3 betrachte, stelle ich Folgendes fest:

Die Indexwerte für die Vorwärts- und Rückwärtsbeziehungen scheinen in jeder Tabelle korrekt zu sein.Die Tabelle object2 enthält anstelle der Spalte vor der Migration zwei Spalten für die umgekehrte Beziehung (ZMYOBJECT wie zuvor und die zusätzlichenZ2_MYOBJECT, das für alle Zeilen leer ist). Es wurde keine weitere Beziehung hinzugefügt, um diese Spalte zu erläutern.In demZ_PRIMARYKEY In der Tabelle werden alle Einträge nach der Migration angezeigt-1 zumZ_MAXWährend vor der Migration für leere Tabellen Null und für aufgefüllte Tabellen die maximale Zeilennummer angezeigt wurde. Manuelles AktualisierenZ_MAX auf die richtigen Werte hat mit der Ausnahme nicht geholfen. AllesZ_SUPER Werte waren korrekt.

Ich habe ein Mapping-Modell erstellt, um festzustellen, ob bei den automatischen Mappings etwas schief aussieht, aber alles in Ordnung ist.

Allgemeine Schemaänderungen:

In der Quellversion des Datenmodells gab es vierzehn Entitäten, von denen nur vier mit Daten gefüllt waren (die App befindet sich noch in der Entwicklung). Sieben waren Entitäten der obersten Ebene und sieben waren Unterentitäten von drei der Entitäten der obersten Ebene.

In der Zielversion des Datenmodells wurden 22 Entitäten hinzugefügt, einige übergeordnete und einige untergeordnete Entitäten, mit Dutzenden von Beziehungen, einschließlich einiger, die zu vorhandenen Entitäten hinzugefügt wurden.

Einige Attribute und Beziehungen wurden aus vorhandenen Entitäten entfernt und andere hinzugefügt. Es wurden keine Datentypen oder Beziehungseinstellungen geändert, keine Attribute oder Beziehungen umbenannt und keine speziellen Zuordnungen erforderlich.

Update (25.02.12): Als ich mit der Arbeit an einem neuen Zwischenmodell begann, fiel mir ein, dass ich die Klasse (RepresentatedClassName) für eine Reihe von Entitäten von NSManagedObject in eine NSManagedObject-Unterklasse geändert, aber keine Klassendateien generiert hatte . Ich hatte nicht den Verdacht, dass dies zu einem Problem führen würde, und in der Tat hat das Erstellen aller Klassendateien mit der Ausnahme nicht geholfen. Ich wollte das nur als einen weiteren Modellwechsel vermerken.

Schlussfolgerungen:

Dies ist eine wilde Vermutung, aber wenn die Anzahl von 36 Entitäten kein Zufall ist, scheint es, dass, wenn "myobject" versucht, "object2" zu beschädigen, es keine gültige Referenz für die Tabelle hat und versucht, die Tabellennummer -1 zu laden , was die Ausnahme verursacht. Die Tatsache, dass eine einfache Zuordnung von[self object2] ist erfolgreich, stimmt jedoch nicht mit dieser Schlussfolgerung überein.

Irgendwelche Ideen?