核心数据迁移技术：移动属性 -> 建模关系

Question

我有一个相当大的基于 Core Data 的数据库架构（约 20 个实体，超过 140 个属性），随着它从我们的 1.x 代码库迁移到我们的 2.x 代码库，它正在经历巨大的变化。

我对执行轻量级迁移非常熟悉，但我对这种特定迁移有点困惑，因为有一些实体曾经将相关对象存储为实体本身的可转换属性，但现在我想迁移那些到实际实体。

这似乎是一个完美示例，说明何时应该使用大量迁移而不是轻量级迁移，但我对此也不太满意。我不熟悉大量迁移，具有此数组的实体之一 -> 发生建模关系转换占用了数据库中约 90% 的行，这些数据库的大小往往超过 200 MB，我知道我们的大部分客户都在使用 iPad 1s。再加上 Apple 文档和 Marcus Zarra 的（优秀的）Core Data 书中关于大量迁移的速度和内存使用情况的反复警告，让我非常谨慎，并寻找另一种方法来处理这种情况。

WWDC 2010 的“掌握核心数据”会话 118（slides here，需要登录，倒数第 9 张幻灯片，标题为“迁移后处理”是我所指的）提到了一种工作方式围绕这个 - 执行迁移，然后使用存储元数据来标记您想要执行的自定义后期处理是否已完成。我认为这可能是要走的路，但对我来说感觉有点 hacky（因为没有更好的词）。另外，我担心会留下在实践中被弃用的属性。前任。如果我将实体 foo 的 barArray 属性移动到实体 foo 和实体 bar 之间的关系中，并且我将 barArray 设为 nil，barArray 仍然作为可以写入和读取的属性存在。解决这个问题的一种潜在方法是通过将它们的名称更改为前面的“不推荐使用”来表示这些属性已被弃用，并且可能覆盖访问器以断言它们是否被使用，但是使用 KVO，没有保证编译-time 解决方案会阻止人们使用它们，而且我讨厌留下“陷阱代码”，特别是因为只要我可能有仍然需要从 1.0 迁移的客户，就必须存在所说的“陷阱代码”。

这变成了比我预期的更多的大脑转储，所以为了清楚起见，我的问题是：
1）在我工作的限制条件下，大规模迁移是一个特别糟糕的选择吗？ （业务关键型应用程序、缺乏大量迁移经验、数据库大小超过 200 MB、数万行、使用运行 iOS 5+ 的 iPad 1 的客户）
2) 如果是这样，第 118 节中描述的迁移后处理技术是我最好的选择吗？
3）如果是这样，我怎样才能立即/最终消除那些“已弃用”的属性，以便它们不再污染我的代码库？

Answer 1

我的建议是远离大量迁移；句号。它在 iOS 上太贵了，很可能会导致不可接受的用户体验。

在这种情况下，我会进行惰性迁移。创建具有关联对象的轻量级迁移。

然后进行迁移，但还没有移动任何数据。

更改该新关系的访问器，使其首先检查旧的可转换对象，如果填充了可转换对象，则将数据拉出，将其复制到新关系，然后将 nil 取出可转换对象。

这样做会导致数据在使用时移动。

现在这种设计存在一些问题。

如果您想对这些新对象使用谓词，那将是……混乱。您将需要进行两次获取。 即使用不会命中该新对象的谓词进行提取，然后在它们进入内存后进行部分提取，以便将可转换对象移过来。