Question

我想将我的参考数据与我的核心数据模型中的用户数据分开，以简化我的应用程序的未来更新（因为，我计划将数据库存储在云上，并且不需要存储参考数据云，因为这是我的应用程序的一部分）。因此，我一直在寻找一种使用fetched属性编写跨店关系的方法。我还没有找到任何示例实现。

我有一个使用2种配置的核心数据模型：

数据模型配置1：UserData（相对于用户的实体）
数据模型配置2：ReferenceData（与应用程序本身相关的实体）

我为这两个配置设置了两个不同的SQLite持久存储。

UserData配置（和存储）包含实体“用户”
ReferenceData config（和store）包含实体“Type”和“Item”。

我想创建两个单向弱关系，如下所示：

“用户”具有唯一的“类型”
“用户”有很多“项目”

以下是我的问题：

如何设置我的属性？
每个关系是否需要2个属性（一个用于存储唯一ID，另一个用于访问我提取的结果）？
可以订购这种弱关系吗？
有人可以给我一个示例实现吗？

作为马库斯回答的后续内容：

浏览论坛和文档，我读到我应该使用我的实体实例的URI表示而不是objectID。这背后的原因是什么？

// Get the URI of my object to reference 
NSURL * uriObjectB [[myObjectB objectID] URIRepresentation];

接下来，我想知道，如何将我的对象B URI（NSURL）存储在我的父对象A中作为弱关系？我应该使用什么属性类型？我该怎么转换呢？我听说过档案......？

然后，我应该以相同的方式检索托管对象（通过非转换/取消归档URIRepresentation）并从URI获取对象

// Get the Object ID from the URI 
NSManagedObjectID* idObjectB = [storeCoordinator managedObjectIDForURIRepresentation:[[myManagedObject objectID] URIRepresentation]];

// Get the Managed Object for the idOjectB ...

最后但并非最不重要的是，我在实体A中声明了两个属性，一个用于持久化URI需求，另一个用于检索direclty对象B？

NSURL * uriObjectB [objectA uriObjectB];

ObjectB * myObjectB = [objectA objectB];

正如你所读到的，我真的很想念一些简单的例子来实现弱关系！我真的很感激一些帮助。

Answer 1

到目前为止，拆分数据是正确的答案。参考数据不应与云同步，特别是因为iCloud对应用程序同步和存储在文档中的内容有软性限制。

要在商店之间创建软引用（它们不需要是SQLite，但对于一般的应用程序性能来说是个好主意），您需要拥有某种可以从另一方引用的唯一键。一个很好的老式外键。

从那里你可以在模型中创建一个fetched属性来引用实体。

虽然不能直接订购此关系，但您可以通过排序索引创建订单，或者如果它具有逻辑排序，那么您可以在检索数据后对其进行排序（我使用便捷方法返回排序数组而不是设定）。

我可以建立一个例子但你真的走在正确的轨道上。唯一有趣的部分是迁移。当您检测到迁移情况时，您需要独立地迁移每个商店，然后构建核心数据堆栈。这听起来很棘手，但实际上并不难。

实施例

想象一下，您在用户存储中有一个UserBar实体，在参考存储中有一个RefBar实体。然后，RefBar将与UserBar建立fetchedProperty“关系”，从而创建ToOne关系。

UserBar
----------
refBarID : NSInteger

RefBar
--------
identifier : NSInteger

然后，您可以在建模器中的RefBar实体上创建一个fetched属性，其谓词为：

$ FETCHED_PROPERTY.refBarID == identifier

允许谓词“userBarFetched”

的名称

现在它将返回一个数组，因此我们想为RefBar添加一个方便的方法

@class UserBar;

@interface RefBar : NSManagedObject

- (UserBar*)userBar;

@end

@implementation RefBar

- (UserBar*)userBar
{
    NSArray *fetched = [self valueForKey:@"userBarFetched"];
    return [fetched lastObject];
}

@end

创建ToMany是相同的，除了你的方便方法会返回一个数组，你会在返回之前对数组进行排序。

如上所述Heath Borders，如果您愿意，可以添加排序到NSFetchedProperty，但您必须在代码中执行此操作。就个人而言，我总是发现它浪费，不使用该功能。如果我可以在建模器中设置排序可能会更有用。

使用ObjectID

我不建议使用ObjectID或URIRepresentation。 ObjectID（以及因此ObjectID的URIRepresentation）可以并且将会改变。每当您迁移数据库时，该值都将更改。你最好不要创建一个不变的GUID。

弱关系

您只需要在关系的M侧有一个值，并存储外部标识符。在对象子类中，您只需要实现检索对象（或对象）的访问器。

Answer 2

我会去一家商店。

对于在云中存储内容，您无论如何都必须序列化数据，无论是JSON还是SQL语句，还是您喜欢的任何方案。

您需要在用户设备上拥有本地数据副本，以便他可以快速离线访问。云存储可以只有用户实体，而本地存储（应用程序的一部分）也可以有参考实体。

我有一个类似的项目，其中包含一个巨大的参考商店（20000条记录），其中包含地理信息和用户生成的内容（“帖子”）。我用一个商店。当我发布应用程序时，“posts”实体也被定义但是为空。当我更新数据模型时，我只需在发货前重新生成整个参考商店。

我认为没有理由在这里寻找跨店解决方案。

与Fetched Properties的交叉存储弱关系？

2 个答案:

实施例

使用ObjectID

弱关系