我对执行轻量级迁移非常熟悉,但是我对这个特定的迁移有点不知所措,因为有一些实体用于将相关对象存储为实体本身的可转换属性,但现在我想将它们迁移到实际实体.

这似乎是一个完美的例子,当你应该使用重型迁移而不是轻量级迁移时,我也不会对此感到高兴.我不熟悉重型迁移,这是拥有此阵列的实体之一 – >模型化关系转换发生占据了数据库中大约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)如果是这样,我怎样才能立即/最终消除那些“弃用”属性,以便它们不再污染我的代码库？