9

我不确定这个问题的格式是否适合这个网站。

基本上，有谁知道是什么说服了 Apple 做出设计决定，即每当您将数据保存到持久存储时 NSManagedObjectID 都会更改？

我可能错了，但这个决定对我来说听起来很可疑。没有明显的优势（它是一个 UUID！它是独一无二的！），但它可以传递 objectID --- 它可以在保存对象时随时更改。

这对我来说是个大问题，因为我使用三个 MOC 系统（背景 MOC -> UI MOC -> 持久 MOC），对象被插入到背景 MOC 中并向上传播并保存。保存是异步的，因为它必须在三个不同的 MOC 上传播并在创建后返回对象，但在将它们保存到持久存储之前非常痛苦，因为我不能依赖传递 objectID。

我做错了什么吗？有谁知道 UUID 在没有通知的情况下随时可变的优势是什么？

我最大的问题是为什么要提供临时 managedObjectID。这有什么意义吗？只是为了迷惑人们尝试使用它吗？

4

2 回答 2

11

我有点困惑为什么你一直说那NSManagedObjectID是一个专门的 UUID。URI 表示可能与 UUID 格式具有相似的外观，但我在文档中没有看到它说“aNSManagedObjectID是 UUID”（我将在下面讨论，它不仅如此）。为什么 Apple 以这种方式设计它超出了 StackOverflow 的范围，所以希望你的问题真的是“Core Data 的设计是什么，我该如何使用它？”

文档所说的（在Managed Object IDs and URIs中）是，如果您想进行这种对象跟踪，您应该添加自己的 UUID 作为属性：

您有时可以从创建自己的唯一 ID (UUID) 属性中受益，该属性可以为新插入的对象定义和设置。这允许您使用谓词有效地定位特定对象（尽管在保存操作之前只能在其原始上下文中找到新对象）。

NSManagedObjectID从不可变的数据结构中可以看出变化的原因。它包括一个persistentStore属性。在您实际保存对象（例如，您可能会调用）之前，这无法确定assignObject:toPersistentStore:。同样，不要考虑NSManagedObjectID它的 URI 表示形式；这只是一种序列化格式。真实 ID 包括持久存储，如文档中所示：

与数据库中的主键一样，标识符包含准确描述持久存储中的对象所需的信息，尽管详细信息并未公开。

在插入对象之前，该标识符无法最终确定。

于 2013-06-17T03:20:11.813 回答
5

我绝不是核心数据方面的专家，但我的理解是，在大多数情况下NSManagedObjectID保证是独一无二的。例外情况是：

  • 当您创建一个新对象但尚未提交时，它的 id 将是临时的。您可以使用 来检查这种情况isTemporaryId。
  • 当后备存储发生变异时，即如果您使用 iCloud 并且您迁移到数据库的新版本。

由于您谈论的是单个生命周期，我假设我们正在考虑第一个选项。如果是这种情况，您应该等到您的更改传播到持久存储之后再获取 id。我认为您可以从同一个对象中获取 id，即创建对象，保留指向它的指针，保存上下文，然后从保留的指针中获取该对象的 id。警告：我从来没有真正这样做过，这只是我根据阅读文档得出的结论。

此外，临时 id 应该一直存在，直到您保存上下文，所以您应该只需要担心一次 - 在第一次保存新对象的上下文之后。

顺便说一句，在我看来，CoreData必须以这种方式实现。如果他们在实际将 id 插入持久存储之前试图保证 id 是唯一的，那么如果两个不同的上下文在提交之前抓取了相同的 id 会发生什么？保证唯一性/防止 id 出现某种竞争条件的唯一方法是在将记录插入数据库时​​找到唯一的 id ...否则，CoreData 必须以某种方式为子上下文插入的每条记录插入一个虚拟值。 ..

于 2013-06-14T15:38:37.867 回答