Po dodaniu nowej wersji modelu Core Data do mojej aplikacji wykonałem lekką migrację, najwyraźniej pomyślnie. Zmigrowany plik został załadowany poprawnie, ale po pierwszej próbie uzyskania dostępu do atrybutu przez określoną relację aplikacja ulega awariiNSRangeException: '*** -[__NSArrayM objectAtIndex:]: index 4294967295 beyond bounds [0 .. 35]'. Ta relacja działała dobrze przed migracją. Wiem z innych postów, że 4294967295 jest naprawdę-1, ale jedyną rzeczą, którą mogę zidentyfikować z 36 elementami w mojej aplikacji / danych jest to, że w modelu danych jest 36 obiektów ogółem (dla porównania, pobierana relacja ma 58 pozycji w tabeli).

Pytanie:

Moje pytanie brzmi: czy na podstawie błędu, który otrzymuję, i rozwiązywania problemów, które zrobiłem poniżej, czy istnieje jakiś rodzaj zmiany schematu, który mógłby przejść przez migrację lekką, ale uszkodził dane po drodze, prowadząc do zauważonego wyjątku? Spróbuję przełamać migrację na mniejsze fragmenty w kilku wersjach, aby wyizolować lub uniknąć tego problemu, ale byłoby miło móc skupić się na konkretnych zmianach schematu, które mogą być winne.

Błąd:

Błąd występuje z następującym kodem w „myobject”:

[[self object2] text];

Relacja object2 jest jedynką, nieobowiązkowa w obie strony i nie zmieniła się relacja do przodu ani odwrotnie między modelami danych. Thetext atrybut prawdopodobnie nie jest istotny, ponieważ w przypadku wystąpienia błęduawakeFromFetch nie został osiągnięty w obiekcie2. Jeśli przypiszę[self object2] do zmiennej przed powyższym stwierdzeniem przydział jest pomyślny i raportydata: <fault>.

Baza danych:

Patrząc na bazę danych w sqlite3, zauważam, co następuje:

Wartości indeksu dla relacji do przodu i odwrotnej wydają się być poprawne w każdej tabeli.Tabela object2 ma dwie kolumny dla odwrotnej relacji zamiast tej przed migracją (ZMYOBJECT jak poprzednio i dodatkoweZ2_MYOBJECT, który jest pusty dla wszystkich wierszy). Żadne inne relacje nie zostały dodane w celu wyjaśnienia tej kolumny.wZ_PRIMARYKEY tabela, wszystkie wpisy po migracji-1 dlaZ_MAX, podczas gdy przed migracją pokazywały zero dla pustych tabel i maksymalną liczbę wierszy dla wypełnionych tabel. Ręczna aktualizacjaZ_MAX do odpowiednich wartości nie pomógł wyjątek. WszystkoZ_SUPER wartości były prawidłowe.

Skonfigurowałem model odwzorowania, aby sprawdzić, czy cokolwiek wyglądało źle z automatycznymi mapowaniami, ale wszystko wyglądało dobrze.

Ogólne zmiany schematu:

W wersji źródłowej modelu danych istniało czternaście podmiotów, z których tylko cztery zostały zapełnione danymi (aplikacja jest nadal rozwijana). Siedem było podmiotami najwyższego poziomu, a siedem było podjednostkami trzech podmiotów najwyższego poziomu.

W docelowej wersji modelu danych dodano dwadzieścia dwie jednostki, niektóre najwyższe i niektóre podjednostki, z dziesiątkami relacji, w tym niektóre dodane do istniejących jednostek.

Niektóre atrybuty i relacje zostały usunięte z istniejących jednostek, a inne zostały dodane. Nie zmieniono żadnych typów danych ani ustawień relacji, nie zmieniono nazw atrybutów ani relacji i nie były wymagane żadne specjalne mapowania.

Aktualizacja (2/25/12): Kiedy zacząłem pracować nad nowym modelem pośrednim, przypomniałem sobie, że zmieniłem klasę (representClassName) dla wielu elementów z NSManagedObject na podklasę NSManagedObject, ale nie wygenerowałem plików klas . Nie podejrzewałem, że spowoduje to problem, a tworzenie wszystkich plików klas nie pomogło w wyjątku. Chciałem tylko zauważyć, że to kolejna zmiana między modelami.

Wnioski:

Jest to szalone przypuszczenie, ale jeśli liczba jednostek 36 nie jest przypadkowa, wydaje się, że gdy „myobject” usiłuje zawinić w „object2”, nie ma prawidłowego odwołania do tabeli i próbuje załadować numer tabeli -1 , powodując wyjątek. Fakt, że proste przypisanie[self object2] jednak odnosi sukces, ale nie zgadza się z tym wnioskiem.

Jakieś pomysły?