您应该有两个持久存储。捆绑中的只读存储和文档目录中的读/写存储。
您可以将两个商店都添加到 中,NSPersistentStoreCoordinator
并从一个中访问它们NSManagedObjectContext
。
如果两个存储具有相同的实体,那么您将需要调用-assignObject:toPersistentStore:
以告诉 Core Data 将实体保存到哪个存储。如果每个底层模型都有不同的实体,那么这不是必需的。
此外,您可以通过确保每个配方具有唯一标识符(您创建的)和注释存储,以便您可以使用获取的属性来检索关联的配方和关联注释,从而将注释“链接”到只读配方。
对象 ID
首先,不要-objectID
在商店之间使用 for 链接。它可以并且确实在迁移期间(和其他时间)发生变化,这将使您的迁移比它需要的要丑陋得多。
移民
迁移非常简单。如果您需要更改只读数据模型,只需更改它并将新版本包含在您的应用程序中。
如果您需要更改读写模型,创建一个新模型,在测试期间使用自动迁移,当您准备好发布时,NSMappingModel
将旧版本写入新版本。
因为这两个持久存储(及其相关模型)没有链接,所以迁移的风险很小。一个“问题”是 Core Data 的模板代码将无法自动解析源模型以进行迁移。要解决此问题,您需要介入并提供帮助:
- 站起来你的目的地
NSPersistentStoreCoordinator
并注意错误。如果您收到迁移错误:
- 找到源模型并
NSManagedObjectModel
使用所有适当的源模型创建一个实例。
- 创建一个实例
NSMigrationManager
并为其提供源模型和目标模型
- 调用
- migrateStoreFromURL: type: options: withMappingModel: toDestinationURL: destinationType: destinationOptions: error:
启动迁移
- 利润!
以这种方式处理迁移需要更多的工作。如果您的两个模型非常分离,您可以做一些不同的事情,但它需要测试(就像所有事情一样):
- 捕获迁移错误
- 仅使用需要迁移的持久存储(和模型)来建立新
NSPersistentStoreCoordinator
的。
- 让那个迁移。
- 拆掉它
NSPersistentStoreCoordinator
并尝试再次站起来NSPersistentStoreCoordinator
。