ios – 核心数据迁移技术：移动属性 – >建模关系
我对执行轻量级迁移非常熟悉,但是我对这个特定的迁移有点不知所措,因为有一些实体用于将相关对象存储为实体本身的可转换属性,但现在我想将它们迁移到实际实体.
这似乎是一个完美的例子,当你应该使用重型迁移而不是轻量级迁移时,我也不会对此感到高兴.我不熟悉重型迁移,这是拥有此阵列的实体之一 – >模型化关系转换发生占据了数据库中大约90％的行,这些数据库的大小往往超过200 MB,我知道很大一部分客户正在使用iPad 1.结合Apple文档和Marcus Zarra(优秀)核心数据书中关于重度迁移的速度和内存使用情况的反复警告,让我非常谨慎,并寻找另一种方法来处理这种情况.
WWDC 2010的“掌握核心数据”会议118(slides here,需要登录,第9张到最后一张幻灯片,标题为“迁移后处理”是我所指的)提到了一种解决这个问题的方法 – 执行迁移,然后使用商店元数据标记您要执行的自定义后期处理是否已完成.我认为这可能是要走的路,但对我来说,感觉有点笨拙(因为缺少一个更好的词).此外,我担心在实践中留下属性,不推荐使用.恩.如果我将实体foo的barArray属性移动到实体foo和实体栏之间的关系中,并且我没有barArray,barArray仍然作为可以写入和读取的属性存在.解决这个问题的一个潜在方法是通过更改名称以使其在前面“弃用”,并且可能覆盖访问者断言(如果使用它们)来表示这些属性已被弃用,但是对于KVO,没有保证编译时间解决方案会阻止人们使用它们,我不喜欢留下“陷阱代码”,特别是因为所谓的“陷阱代码”必须存在,只要我可能还有需要从1.0迁移的客户.
这变成了比我预想的更多的脑溢流,所以为了清楚起见,我的问题是：
1)在我正在努力的限制下,重度迁移是一个特别糟糕的选择吗？ (业务关键型应用程序,缺乏大量迁移的经验,数据库超过200 MB,数万行,使用运行iOS 5的iPad 1的客户)
2)如果是这样,会话118中描述的迁移后处理技术是我最好的选择吗？
3)如果是这样,我怎样才能立即/最终消除那些“弃用”属性,以便它们不再污染我的代码库？
解决方法
在这种情况下,我会做一个懒惰的迁移.创建具有关联对象的轻量级迁移.
然后进行迁移,但不要移动任何数据.
更改新关系的访问器,以便它首先检查旧的可变形,如果填充了可变形,则将数据拉出,将其复制到新关系,然后输出可转换的nil.
执行此操作将导致数据在使用时移动.
现在这个设计存在一些问题.
如果你想对这些新对象使用谓词,那将是……混乱.你会想要两次获取.即,使用不匹配该新对象的谓词进行提取,然后在它们是内存后执行一个段提取,以便可转换的方式移过.
以上是来客网为你收集整理的ios – 核心数据迁移技术：移动属性 – >建模关系全部内容，希望文章能够帮你解决ios – 核心数据迁移技术：移动属性 – >建模关系所遇到的程序开发问题。
如果觉得来客网网站内容还不错，欢迎将来客网网站推荐给程序员好友。
