自定義 Core Data 遷移似乎是一個不太起眼的話題。蘋果在這方面只提供了很少的文檔，若是初次涉足此方面內容，很可能會變成一個可怕的經歷。鑒于客戶端程序的性質，你無法測試你的用戶所生成的數據集的所有可能排列。此外，解決遷移過程中出現的問題會很困難，而因為極有可能你的代碼依賴于最新的數據模型，所以回退并不是一個可選的處理辦法。
在本文中，我們將走一遍搭建自定義 Core Data 遷移的過程，并著重于數據模型的重構。我們將探討從舊模型中提取數據并使用這些數據來填充具有新的實體和關系的目標模型。此外，會有一個包含單元測試的示例項目用于演示兩個自定義遷移。
需要注意的是，如果對數據模型的修改只有增加一個實體或可選屬性，輕量級的遷移是一個很好的選擇。它們非常易于設置，所以本文只會稍稍提及它們。若想知道輕量級遷移的應用場合，請查看官方文檔。
這就是說，如果你需要快速地在你的數據模型上進行相對復雜的改變，那么自定義遷移就是為你準備的。
映射模型 (Mapping Models)
當你要升級你的數據模型到新版，你將先選擇一個基準模型。對于輕量級遷移，持久化存儲會為你自動推斷一個映射模型。然而，如果你對新模型所做的修改并不被輕量級遷移所支持，那么你就需要創建一個映射模型。一個映射模型需要一個源數據模型和一個目標數據模型。NSMigrationManager能夠推斷這兩個模型間的映射模型。這使得它很誘人，可用來一路創建每一個以前的模型到最新模型之間的映射模型，但這很快就會變成一團亂麻。對于每一個新版模型，你需要創建的映射模型的量將線性增長。這可能看起來不是個大問題，但隨之而來的是測試這些映射模型的復雜度大大提高了。
想像一下你剛剛部署一個包含版本 3 的數據模型的更新。你的某個用戶已經有一段時間沒有更新你的應用了，這個用戶還在版本 1 的數據模型上。那么現在你就需要一個從版本 1 到版本 3 的映射模型。同時你也需要版本 2 到版本 3 的映射模型。當你添加了版本 4 的數據模型后，那你就需要創建三個新的映射模型。顯然這樣做的擴展性很差，那就來試試漸進式遷移吧。
漸進式遷移 (Progressive Migrations)
與其為每個之前的數據模型到最新的模型間都建立映射模型，還不如在每兩個連續的數據模型之間創建映射模型。以前面的例子來說，版本 1 和版本 2 之間需要一個映射模型，版本 2 和版本 3 之間需要一個映射模型。這樣就可以從版本 1 遷移到版本 2 再遷移到版本 3。顯然，使用這種遷移的方式時，若用戶在較老的版本上遷移過程就會比較慢，但它能節省開發時間并保證健壯性，因為你只需要確保從之前一個模型到新模型的遷移工作正常即可，而更前面的映射模型都已經經過了測試。
總的想法就是手動找出當前版本 v 和版本 v+1 之間的映射模型，在這兩者間遷移，接著繼續遞歸，直到持久化存儲與當前的數據模型兼容。
這一過程看起來像下面這樣（完整版可以在示例項目里找到）：
這段代碼主要來源于Marcus Zarra，他寫了一本很棒的關于 Core Data 的書，查看這里。
自 iOS 7 和 OS Mavericks以來，Apple 將 SQLite 的日志模式改寫為預寫式日志 (Write-Ahead Logging)， 這意味著數據庫事務都被依附到一個 -wal 文件中。這有可能導致數據丟失和異常。為了數據的安全，我們會將日志模式改寫為回溯模式。而如果我們想要遷移數據（或者為了以后備份），我們可以將一個字典傳遞給-addPersistentStoreWithType:configuration:URL:options:error:來完成改寫。
遷移策略
NSEntityMigrationPolicy是自定義遷移過程的核心。蘋果的文檔中有這么一句話:
NSEntityMigrationPolicy的實例為一個實體映射自定義的遷移策略。
簡單的說，這個類讓我們不僅僅能修改實體的屬性和關系，而且還能任意添加一些自定義的操作來完成每個實體的遷移。
遷移示例
假設我們有一個帶有簡單的數據模型的書籍應用。這個模型有兩個實體：User和Book。Book實體有一個屬性叫做authorName。我們想改善這個模型，添加一個新的實體：Author。同時我們想為Book和Author建立一個多對多的關系，因為一本書籍可有多個作者，而一個作者也可寫多本書籍。我們將從Book對象里取出authorName用于填充一個新的實體并建立關系。
一開始我們要做的是基于第一個數據模型增加一個新版模型。在這個例子里，我們添加了一個Author實體，它與Book還有多對多的關系。
現在數據模型已經是我們所需要的，但我們還需要遷移所有已存在的數據，這就該NSEntityMigrationPolicy出場了。我們創建NSEntityMigrationPolicy的一個子類----MHWBookToBookPolicy。在映射模型里，我們選擇Book實體并設置它作為公共部分（Utilities section）中的自定義策略。
同時我們使用 user info 字典來設置一個modelVersion，它將在未來的遷移中派上用場。
在MHWBookToBookPolicy中，我們將重載-createDestinationInstancesForSourceInstance:entityMapping:manager:error:方法，它允許我們自定義如何遷移每個 Book 實例。如果modelVersion的值不是 2，我們將調用父類的實現，否則我們就要做自定義遷移。我們插入基于映射的目標實體的新NSManagedObject對象到目標上下文。然后我們遍歷目標實例的屬性鍵值并與來自源實例的值一起填充它們。這將保證我們保留現存數據并避免設置任何我們已經在目標實例中移除的值。
然后我們將基于源實例的值創建一個Author實體。但若多本書有同一個作者會發生什么呢？我們將使用NSMigrationManager的一個 category 方法來創建一個查找字典，確保對于同一個名字的作者，我們只會創建一個Author。
最后，我們需要告訴遷移管理器在源存儲與目的存儲之間關聯數據：
NSMigrationManager的 category 方法:
一個更復雜的遷移
過了一會，我們又想把fileURL這個屬性從Book實體里提出來，放入一個叫做File的新實體里。同時我們還想修改實體之間的關系，以便User可與File有一對多的關系，而反過來File和Book有多對一的關系。
在之前的遷移中，我們只遷移了一個實體。而現在當我們添加了File后，事情變得有些復雜了。我們不能簡單地在遷移一個Book時插入一個File實體并設置它與User的對應關系，因為此時User實體還沒有被遷移，之間的關系也無從談起。我們必須考慮遷移的執行順序。在映射模型中，是可以改變實體映射的順序的。具體到這里的例子，我們想將UserToUser映射放在BookToBook映射之上。這保證了User實體會比Book實體更早遷移。
添加一個File實體的途徑和創建Author的過程相似。我們在MHWBookToBookPolicy中遷移Book實體時創建File對象。我們會查看源實例的User實體，為每個User實體創建一個新的File對象，并建立對應關系：
大數據集
如果你的存儲包含了大量數據，以至到達一個臨界點，遷移就會消耗過多內存，Core Data 提供了一個以數據塊（chunks）的方式遷移的辦法。蘋果的文檔有簡要地提到這件事。解決辦法是使用多映射模型分開你的遷移并為每個映射模型遷移一次。這要求你有一個對象圖（object graph），在其中，遷移可被分為兩個或多個部分。為了支持這一點而需要添加的代碼其實很少。
首先，我們更新遷移方法以支持使用多個映射模型來遷移。已知映射模型的順序很重要，我們將通過代理方法請求它們：
現在，我們如何知曉哪一個映射模型被用于這個特定的源模型呢？此處的 API 可能顯得有些笨拙，但以下的解決方法確實完成了工作。在代理方法中，我們找出源模型的名字并返回相關的映射模型：
我們將為NSManagedObjectModel添加一個 category，以幫助我們找出它的文件名： We’ll add a category onNSManagedObjectModelthat helps us figure out its filename:
由于User在前面的例子（沒有源關系映射）中被從對象圖中隔離，因此遷移User的過程將省事很多。我們將從第一個映射模型中移除UserToUser映射，然后創建一個僅有UserToUser的映射。不要忘記在映射模型列表中返回新的User映射模型，因為我們正在其它映射中設置新關系
單元測試
為此應用建立單元測試異常簡單：
將相關數據填入舊存儲*。
將產生的持久性存儲文件復制到你的測試目標。
編寫測試斷言符合最新的數據模型。
運行測試，遷移數據到新的數據模型。
*這很容易完成，只需在模擬器里運行一下你應用最新的版本（production version）即可
步驟 1 和 2 很簡單。步驟 3 留給讀者作為練習，然后我會引導你通過第 4 步。
當持久化存儲文件被添加到單元測試目標上時，我們需要告知遷移管理器把那個存儲遷移至我們的目標存儲。在示例項目中所示如下：
把下面的代碼放到一個父類，以便于在測試的類中復用：
結論
輕量級遷移是直接在 SQLite 內部發生。這相對于自定義遷移來說非常快速且有效率。自定義遷移要把源對象讀入到內存中，然后拷貝值到目標對象，重新建立關系，最后插入到新的存儲中。這樣做不僅很慢，而且當遷移大數據集時，由于內存大小的限制，它還會引起系統強制回收內存問題。
添加數據前盡量考慮完全
在處理任何數據持久性問題時最重要的事情之一就是仔細思考你的模型。我們希望模型是可持續發展的。在最開始創建模型的時候盡量考慮完全。添加空屬性或者空實體也比以后進行遷移時候創建好的多，因為遷移很容易出現錯誤，而未使用的數據就不會了。
調試遷移
測試遷移時一個有用的啟動參數是-com.apple.CoreData.MigrationDebug。設置為 1 時，你會在控制臺收到關于遷移數據時特殊情況的信息。如果你熟悉 SQL 但不了解 Core Data，設置-com.apple.CoreData.SQLDebug為 1 可在控制臺看到實際操作的 SQL 語句。
