问题标签 [nsmergepolicy]

只是想知道是否有一种在 a 中插入项目的好方法CoreData db？

或者有没有办法让我将 CoreData 数据库视为一个集合？

我的意思是，如果我将一个项目插入数据库并且那里已经有一个相同的冗余项目，那么数据库会忽略它。有什么方便的方法吗？或者我每次插入时都必须查询以避免冗余？

我是 IOS 开发的新手，并且在使用 coredata 时跌跌撞撞。

我创建了一个AppPage实体，其中的pageId属性标记为唯一约束。

现在我可以使用以下代码在AppPage中插入一行：

现在，当我在这里想要的是，如果再次以pageId为 12 且 pContent为新更新信息的行，实体中的同一行应该使用更新的信息进行更新。

我用谷歌搜索并发现

getAppDelegate().persistentContainer.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy

但是设置NSMergeByPropertyObjectTrumpMergePolicy在我的 XCode(v8.3.2) 中给了我一个编译错误

如果行不存在，则基本上插入一行，否则使用给定的 id 更新行。

这是 Xcode 抛出的编译错误。

Use of unresolved identifier NSMergeByPropertyObjectTrumpMergePolicy

我有一个核心数据堆栈，它只显式使用主上下文，并且只在 context.performAndWait 块中更改/创建持久对象。如果我需要背景上下文，我总是使用以下代码块：

主上下文的合并策略在创建 persistentStore 时设置为 NSOverwriteMergePolicy，当我保存后台上下文时，我希望用后台上下文中创建的任何“新”对象覆盖主上下文中的任何“旧”对象. 相反，我得到了一个 NSConstraintConflict 错误，因为后台上下文使用默认的合并策略（不知道为什么，我希望它继承主上下文的合并策略。）当我明确设置后台上下文的合并策略时，我最终得到了根据我设置的约束不应该重复的对象的重复。在这种情况下，clientID 属性对于任何给定的 Client 实体都必须是唯一的。

我觉得我在某种程度上没有正确地合并上下文。我现在这样做的方式只是保存背景上下文，然后保存主上下文，或多或少如上所示。但是，如果我没有正确合并，当在背景上下文中创建的对象与主上下文中的对象具有相同的属性时，为什么会发生约束错误？当我在主上下文上执行获取请求时，为什么会出现重复项？

我只有大约两个月的时间使用核心数据，我所知道的一切都来自文档或这里，所以我确信有些东西我只是不知道。关于我做错了什么的任何想法？

我的 Swift 应用程序从在线 API 以 JSON 形式下载 3 个数据库，然后将 JSON 对象转换为 CoreData 对象，因此该应用程序可以在互联网访问之外运行。

我有一个实体客户端，它与地址类型的实体有 toMany 关系。Address 与实体 Client 具有一对一的关系。

客户 <-->> 地址

客户端到地址的关系有一个级联删除规则，地址到客户端的关系有​​一个无效删除规则。

Client 对 id 属性有唯一性约束，上下文总是使用 NSMergePolicyType.overwriteMergePolicyType。

当一个新的客户端 NSManagedObject 被实例化，上下文被保存，并找到一个具有相同 ID 的客户端时，新的客户端会覆盖旧的客户端，有一个很大的警告——由于某种未知的原因，旧的地址对象仍然存在，现在链接到新客户。这会在每次重新加载缓存/数据库时生成每个地址的新副本。

我有多个实体，它们具有这样的关系和唯一性，它们运行到相同的结果中——多个对象实例的重复。

对于像地址这样的对象，没有一个属性可以封装容器中所有其他地址对象之间的唯一性。它必须是所有属性（地址 1、地址 2、城市、州、邮编等）的总和，根据另一个地址的所有属性的总和检查其唯一性。所以我不确定如何通过唯一性约束来实现这一点——据我所知，唯一性约束不能用 if 逻辑来扩展。

另一种解决方案是更改策略的合并行为，或创建自定义合并策略，以确保在将旧对象替换为新对象之前实际删除旧对象（向下级联到一对多关系对象）。

我对CoreData 或objective-c 不够熟悉，无法了解到目前为止我能找到的关于该主题的任何内容。

是否有人对如何 A. 扩展唯一性约束功能、B. 定义合并策略行为或 C. 以其他方式防止上述地址对象重复有什么建议？

编辑：

我怀疑我对唯一性约束的假设是错误的 - 请在此处查看我的单独问题

最近我接手了一个基于 Core Data 的现有 iOS 项目的开发。该项目使用后台同步从服务器检索和更新数据并将其写入核心数据。但是，在某些情况下，这会导致以下块崩溃：

上述块的上下文是较早在后台上下文中创建的：

该应用程序不会在 catch 块中引发错误，但在访问上下文时会停止工作。找不到进一步的日志详细信息。

在我见过的大多数 Core Data 示例中，persistentContainer.viewContext被使用或newBackgroundContext()用于后台操作。在这个应用程序中，在主线程上，应用程序默认使用注册到对象本身的上下文。请参见以下示例：

属性的值managedObjectContext是注册到对象的上下文。因此，我的假设是值发生了变化，因此使用了不正确的上下文。我认为这会导致线程访问问题。

当直接使用注册的上下文时，是否有其他人遇到过这些问题，您是如何解决的？

我正在构建一个从 Web 服务获取大量数据的应用程序。该应用程序由彼此有关系的不同条目组成。举个例子，假设我正在构建一个电视节目跟踪应用程序，所有数据都来自网络服务，但我想将剧集标记为已观看，这是迄今为止一个条目的自定义属性。所有这些都保存在 Core Data 中。我有这些条目：

1. 显示⇒有许多季节和剧集
2. 季节⇒有很多集和一个节目
3. 情节⇒有一个节目和一个季节

我目前正在努力解决的主要部分是，当网络服务具有数据的更新版本时，我如何才能最好地更新所有这些条目（也许节目有一个新的季节或修复了一些错误的数据）。此时，这些条目上唯一与 Web 服务提供的数据不同的自定义属性是我在 Episode 条目上创建的 watch 属性。

到目前为止，我尝试了不同的方法，例如删除旧数据并仅添加新数据（此处的自定义监视属性是一个问题），并且我还研究了合并策略，例如NSMergeByPropertyObjectTrumpMergePolicy，但这对关系并不好，我得到了那里的路障。

有没有更好的方法或最佳实践来解决这个问题？

在上下文中应用overwrite合并策略时，对多关系的合并结果有时会让我感到困惑。例如：

原始值：

如果我只更改属性的值，如下所示，在上下文 1 上所做的更改将完全被上下文 2 覆盖。

但是，当我像下面这样更新多对多关系时hobbies，合并结果是空的，而不是[reading].

问题：谁能解释为什么在这种情况下一对多关系没有被覆盖？谢谢！

我的应用程序使用 CoreData + CloudKit 同步。一些 CoreData 实体Item可以通过 iCloud 的共享数据库共享。该应用程序仅使用 1 NSPersistentContainer，但它具有 2 NSManagedContexts、 thevisualContext和 a backgroundContext。
因此，在保存上下文期间，可能会出现两种类型的合并冲突：1）如果两个上下文都尝试Item在不同的状态下保存相同的内容，以及 2）如果我的持久容器和 iCloud 同步尝试Item在不同的状态下保存相同的内容。

Item有一个属性updatedAt，并且应用程序要求始终Item保存最后更新的版本。
出于一致性原因，我不能按属性合并。只能存储完整Item的对象，要么存储在托管上下文中，要么存储在托管上下文中，或者持久存储。
但是不能使用标准的合并策略：NSRollbackMergePolicy忽略托管上下文中的更改，并获取持久副本，同时NSOverwriteMergePolicy用托管上下文中的对象覆盖持久存储。但我必须使用Item最新的updatedAt. 因此我必须使用自定义合并策略。

很难找到任何提示如何做到这一点。我找到了两个带有演示代码的教程。最好的一本是 Florian Kugler 和 Daniel Eggert 所著的Core Data一书，其中有一个关于自定义合并策略的部分，以及此处的相关代码。另一个是 Deepika Ramesh 的帖子，其中包含代码。但是我不得不承认，我并没有完全理解这两者。但是根据他们的代码，我尝试设置自己的自定义合并策略，该策略将分配给mergePolicy两个托管上下文的属性。这里是：

我的第一个问题是这段代码是否有意义。我问这个是因为合并冲突很难测试。
具体来说，我显然必须使用 中的任何标准合并属性super.init(merge: .overwriteMergePolicyType)，尽管显然哪个并不重要，因为我使用的是自定义合并冲突解决方案。