为什么NSManagedObjectID会改变？

Question

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

基本上，有谁知道是什么说服了苹果在将数据保存到持久化存储时做出NSManagedObjectID更改的设计决策？

我可能错了，但我觉得这个决定很可疑。没有明显的优势(这是一个UUID！它是唯一的！)，但是它会使经过objectID的对象--它可以在保存对象时随时在您的脚下改变。

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

我是不是做错了什么？有人知道UUID在没有通知的情况下随时可变的好处是什么吗？

我最大的问题是为什么会提供临时managedObjectID。这里面有什么意义吗？这仅仅是为了迷惑人们试图使用它吗？

Answer 1

我有点困惑，为什么您一直说NSManagedObjectID是一个专门的UUID。URI表示形式可能与UUID格式类似，但我在文档中没有看到任何地方显示“NSManagedObjectID是UUID”(正如我将在下面讨论的那样，不止如此)。为什么苹果用这种方式设计它超出了StackOverflow的范围，所以希望你的问题是“什么是核心数据的设计，我如何处理它？”

文档告诉我们(在Managed Object IDs and URIs中)，如果您想要进行这种对象跟踪，您应该添加自己的UUID作为属性：

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

从不可变的数据结构可以看出NSManagedObjectID更改的原因。它包括一个persistentStore属性。在实际保存对象(例如，您可以调用assignObject:toPersistentStore: )之前，这是不确定的。同样，不要从URI表示的角度来考虑NSManagedObjectID；这只是一种序列化格式。真正的ID包括持久化存储，如docs中所示：

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

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

Answer 2

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

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

既然你说的是一个单一的生命周期，我想我们要考虑的是第一个选择。如果是这样的话，您应该等到更改传播到持久存储之后才获得id。我认为您可以从同一个对象获得id，即创建对象，保留指向该对象的指针，保存上下文，然后从保留的指针中获取该对象的id。警告:我从来没有这样做过，这只是我根据阅读文档得出的结论。

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

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