我有一个相当大的基于核心数据的数据库模式（大约20个实体，超过140个属性），当它从我们的1.x代码库迁移到2.x代码库时，正在经历大的变化。
我对执行轻量级迁移非常熟悉，但是我对这个特定的迁移有点不知所措，因为有一些实体用于将相关对象存储为实体本身的可转换属性，但现在我想迁移那些到实际的实体。
这似乎是一个完美的示例，当你应该使用大量迁移而不是轻量级迁移时，我对此也不太满意。我不熟悉重型迁移，这是拥有此阵列的实体之一 - ＆gt;模型化关系转换发生占据了数据库中大约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）如果是这样，我怎样才能立即/最终消除那些“弃用”属性，以便它们不再污染我的代码库？
答案 0 :(得分：6)
我的建议是远离繁重的移民;完全停止。它在iOS上太贵了，很可能会导致不可接受的用户体验。
在这种情况下，我会做一个懒惰的迁移。创建一个包含关联对象的轻量级迁移。
然后执行迁移，但尚未移动任何数据。
更改新关系的访问者，以便它首先检查旧的可变形关系，如果填充了可转换数据，则将数据拉出，将其复制到新关系，然后将变换为nil。
执行此操作将导致数据在使用时移动。
现在这个设计存在一些问题。
如果你想对这些新对象使用谓词，那将是......混乱。你会想要两次获取。 即使用没有命中该新对象的谓词进行提取，然后在它们是内存后执行一个段提取，以便可转换为移动。