Mam dość duży schemat bazowy oparty na danych podstawowych (~ 20 jednostek, ponad 140 właściwości), który przechodzi duże zmiany, ponieważ migruje z naszej bazy kodu 1.x do bazy kodu 2.x.

Jestem bardzo zaznajomiony z wykonywaniem lekkich migracji, ale jestem trochę zafałszowany tą konkretną migracją, ponieważ istnieje kilka elementów, które służyły do ​​przechowywania powiązanych obiektów jako transformowalnych atrybutów w samej jednostce, ale teraz chcę je przenieść do rzeczywistych jednostek .

To wygląda jakidealny przykład kiedy powinieneś użyć ciężkiej migracji zamiast lekkiej, ale ja też nie jestem zbyt szczęśliwy z tego powodu. Nie jestem zaznajomiony z dużymi migracjami, jedna z encji, która ma tę tablicę -> wystąpienie modelowanej konwersji relacji zajmuje ~ 90% wierszy w bazie danych, te bazy danych mają rozmiar większy niż 200 MB i wiem spora część naszych klientów korzysta z iPada 1s. W połączeniu z powtarzającymi się ostrzeżeniami zawartymi w dokumentacji Apple oraz (doskonałą) książką Marcusa Zarry (Core Data) na temat szybkości i wykorzystania pamięci przez ciężką migrację sprawiają, że jestembardzo ostrożny i szukając innego sposobu radzenia sobie z tą sytuacją.

Sesja WWDC 2010 „Mastering Core Data” 118 (slajdy tutaj, wymaga logowania, od 9 do ostatniego slajdu, z tytułem „Post-Processing Migracja”, o czym mówię) wspomina o sposobie obejścia tego problemu - przeprowadzania migracji, a następnie używania metadanych sklepu do oznaczania, czy lub Nie wykonano niestandardowego przetwarzania postu, które chcesz wykonać. Myślę, że to może być droga, ale wydaje mi się, że jest trochę hacky (z braku lepszego słowa). Obawiam się również, że pozostanie w pobliżu atrybutów, które są w praktyce, przestarzałe. dawny. jeśli przeniosę atrybut barArray elementu foo na relację między jednostką foo i paskiem encji, a następnie wyłączyłem barArray, barArray nadal istnieje jako atrybut, który można zapisać i odczytać. Potencjalnym sposobem rozwiązania tego problemu byłoby zasygnalizowanie, że atrybuty te są przestarzałe poprzez zmianę ich nazw na „przestarzałe” z przodu, a także być może przesłonięcie akcesorów do potwierdzenia, jeśli są używane, ale w przypadku KVO nie ma gwarancji kompilacji rozwiązanie czasowe, które uniemożliwi korzystanie z nich przez ludzi, i nie znoszę pozostawienia „kodu pułapki”, zwłaszcza że „kod pułapki” będzie musiał istnieć tak długo, jak potencjalnie będę miał klientów, którzy nadal muszą migrować z 1.0.

To zamieniło się bardziej w zrzut mózgu niż zamierzałem, więc dla jasności moje pytania to:
1) Czy ciężka migracja jest szczególnie złym wyborem z ograniczeniami, w których pracuję? (aplikacja o znaczeniu krytycznym dla biznesu, brak doświadczenia z ciężkimi migracjami, bazy danych o rozmiarze ponad 200 MB, dziesiątki tysięcy wierszy, klienci korzystający z iPada 1 z systemem iOS 5+)
2) Jeśli tak, czy technika post-processingu migracji opisana w sesji 118 jest moim najlepszym rozwiązaniem?
3) Jeśli tak, jak mogę od razu / ostatecznie wyeliminować te „przestarzałe” atrybuty, aby nie zanieczyszczały już mojej bazy kodu?