我有一个相当大的基于核心数据的数据库模式（约 20 个实体，超过 140 个属性），当它从 1.x 代码库迁移到 2.x 代码库时，它正在经历巨大的变化。
我非常熟悉执行轻量级迁移，但我对这种特定的迁移有点困惑，因为有一些实体用于将相关对象存储为实体本身的可转换属性，但现在我想将它们迁移到实际实体。
这似乎是一个perfect何时应该使用重度迁移而不是轻量级迁移的示例，但我对此也不太满意。我不熟悉大量迁移，发生此数组 -> 建模关系转换的实体之一占用了数据库中约 90% 的行，这些数据库的大小往往超过 200 MB，我知道我们很大一部分客户正在使用 iPad 1。再加上 Apple 文档和 Marcus Zarra 的（优秀的）Core Data 书中关于大量迁移的速度和内存使用情况的反复警告，让我very保持警惕，并寻找另一种方法来处理这种情况。
WWDC 2010 的“掌握核心数据”会议 118 (幻灯片在这里 http://adcdownload.apple.com//wwdc_2010/wwdc_2010_video_assets__pdfs/118__mastering_core_data.pdf，需要登录，倒数第 9 张幻灯片，标题为“迁移后处理”就是我所指的）提到了一种解决此问题的方法 - 执行迁移，然后使用存储元数据来标记是否或您想要执行的自定义后处理尚未完成。我认为这可能是可行的方法，但对我来说感觉有点老套（因为缺乏更好的词）。另外，我担心留下一些实际上已被弃用的属性。前任。如果我将实体 foo 的 barArray 属性移入实体 foo 和实体 bar 之间的关系，并且将 barArray 置空，则 barArray 仍然作为可写入和读取的属性存在。解决这个问题的一个潜在方法是通过将它们的名称更改为前面“已弃用”来表明这些属性已被弃用，并且可能覆盖访问器以断言它们是否被使用，但使用 KVO 时，无法保证编译-时间解决方案将阻止人们使用它们，而且我讨厌留下“陷阱代码”，特别是因为只要我可能有仍然需要从 1.0 迁移的客户，就必须存在所说的“陷阱代码”。
这变成了比我预想的更多的脑转储，所以为了清楚起见，我的问题是：
1) 考虑到我工作的限制，大量迁移是否是一个特别糟糕的选择？ （业务关键型应用程序、缺乏大量迁移经验、数据库大小超过 200 MB、数万行、使用运行 iOS 5+ 的 iPad 1 的客户）
2) 如果是这样，第 118 节中描述的迁移后处理技术是我最好的选择吗？
3）如果是这样，我如何立即/最终消除那些“已弃用”的属性，以便它们不再污染我的代码库？
我的建议是远离大量移民；句号。它在 iOS 上太昂贵，并且很可能会导致不可接受的用户体验。
在这种情况下，我会进行惰性迁移。创建具有关联对象的轻量级迁移。
然后进行迁移但是还不要移动任何数据.
更改该新关系的访问器，以便它首先检查旧的可转换对象，如果可转换对象已填充，它将提取数据，将其复制到新关系，然后将可转换对象置为 nil。
这样做会导致数据在使用时移动。
现在这个设计存在一些问题。
如果您想对这些新对象使用谓词，那将会变得……混乱。您将需要进行两遍提取。i.e.使用不会命中该新对象的谓词进行提取，然后在它们进入内存后进行部分提取，以便将可转换对象移过去。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
