问题标签 [nsmanagedobjectid]

我真的很想避免使用NSManagedObjectID将我的模型结构连接到它们的 CoreData 对象的方法。我的意思是这样的：

假设我Book在 CoreData 中有一个实体，然后我有一个像这样的模型结构来代表我的模型层：

我不喜欢这种方法。它使使用结构变得乏味，例如，测试很烦人，因为我总是必须生成虚拟 objectId 或使其成为BookModel.objectID可选的。

我希望拥有的是实体内部的id类型属性。这将很容易连接到结构，并且还允许结构在没有数据库的情况下正确存在：UUIDBook

我注意到您实际上可以UUID在实体中拥有属性。但是，性能差异似乎是巨大的。我创建了一个尝试获取单个对象 10000 次的示例。

首先，我使用contexts获取它们object(with: NSManagedObjectID)。我将所有可能的 objectId 硬编码在一个数组中，并且每次都随机传递一个。

然后，我使用了一个简单的获取请求，其中NSPredicate传递了一个随机 UUID。

执行时间的差异很大：

使用 ObjectID：0.015282376s

使用 UUID：1.093346287s

然而，奇怪的是第一种方法实际上并没有产生任何 SQL 查询（我使用启动参数记录了它们-com.apple.CoreData.SQLDebug 4）。这可以解释速度，但不能解释为什么它根本不需要与数据库通信。

我进行了一些研究，但无法真正弄清楚object(with: NSManagedObjectID)幕后实际上做了什么。

这是否意味着，使用“自定义”UUID属性不是一个好主意？我真的很感激对此的任何见解！

我有以下关系：

播放列表可能有一对多的歌曲，而歌曲可能属于一对多的播放列表。

我的问题在于获取特定播放列表中歌曲的顺序 - 例如，

• 在播放列表 1 中，顺序可能为 3，
• 在播放列表 2 中，顺序可能为 1，
• 在播放列表 3 中，顺序可能是 5，等等。

此外，可以更改播放列表中歌曲的顺序，因为它们在表格视图中列出。

我现在想跟踪订单。

我尝试了以下方法：

1. 为 Song 实体创建一个新属性“PlaylistOrders” - 使用代表订单的 NSSet（播放列表的订单和 ManagedObjectId），
2. 创建一个名为“PlaylistOrders”的新实体并将其连接到“Song”。此新实体还包含一个可转换的 objectId (ManagedObjectId)。

这两种方法似乎都非常容易出错 - 此外，我经常收到警告，例如“'NSKeyedUnarchiveFromData'不应该用于取消归档，将在未来的版本中删除”。

有没有更好、更复杂的方法在不同的播放列表中存储和检索歌曲的顺序？