Mam aplikację i wiele historycznych wersji bazy danych. Nasi użytkownicy są zwykle użytkownikami „raz w roku”, co oznacza, że nigdy nie będziesz mieć pewności, na której wersji bazy danych działa ich aplikacja.
Teraz w mojej nowej wersji bazy danych muszę przeprowadzić niestandardową migrację. Metoda, której używam, jest opisana w tym samouczku: http://9elements.com/io/index.php/customizing-core-data-migrations/
Podsumowując: muszę stworzyć niestandardowe modele mapowania, aby móc pisać własne zasady migracji dla niektórych pól.
Teraz, gdy tworzę niestandardowy model mapowania, muszę wybrać źródło „xcdatamodel” i miejsce docelowe „xcdatamodel” (gdzie „miejsce docelowe” to nowa wersja mojej bazy danych).
Moje pytanie brzmi, czy chcę zrobić ten zwyczajmigracja ze wszystkich możliwych wersji, czy muszę utworzyć wiele niestandardowych modeli mapowania, wszystkie z innym źródłem, czy może jest to mądrzejszy sposób? A może CoreData jest wystarczająco inteligentny, aby to rozpoznać?
Odpowiedzi:
2 dla odpowiedzi № 1Krótka odpowiedź brzmi: tak; musisz przetestować comigracja z każdego modelu źródłowego do bieżącego modelu docelowego. Jeśli migracja wymaga niestandardowego mapowania, musisz mieć mapowanie dla tej pary.
Podstawowe dane nie rozumieją wersji; tylkorozumie źródło i cel. Jeśli nie ma sposobu na przejście z punktu A do punktu B, nie powiedzie się. Jeśli może migrować automatycznie z A do B i masz włączoną opcję, to zrobi to. W przeciwnym razie wymagana jest ciężka (ręczna) migracja.
Pamiętaj, że ciężkie migracje to BARDZO pracaintensywne i zdecydowanie polecam ich unikać. Przekonałem się, że eksportowanie (na przykład do JSON) i importowanie danych jest o wiele bardziej wydajne, a następnie przeprowadzanie dużej migracji.
0 dla odpowiedzi nr 2
Wystarczy mieć spójną sekwencyjną serię modeli migracji do aktualnej wersji. Podstawowe dane są wystarczająco „inteligentne”, aby wykonać migracje, o których nakazujesz migrację w podanej kolejności.