swift - 合并不同上下文的数据，自动MergesChangesFromParent用法

Question

我有一个使用 CoreData 并具有多个后台上下文 (NSManagedObjectContext) 的应用程序。

在编写一些测试时，我观察到一种奇怪的行为，这似乎与官方文档存在争议:一个上下文中的更改会自动传播到另一个上下文，而 .automaticallyMergesChangesFromParent 在两个上下文中都设置为 false。

两个上下文都是从 NSPercientContainer 接收的 - 一个来自 .viewContext，另一个 - 使用 .newBackgroundContext() 函数。

如save说，在上下文保存时，更改将提交到上下文的父存储，即 NSPercientContainer。
但事实上，更改也会出现在另一个上下文中，尽管事实上automaticMergesChangesFromParent == false(它是默认值)。

let persistentContainer = NSPersistentContainer(name: "TESTING")
let mainContext = persistentContainer.viewContext
let otherContext = persistentContainer.newBackgroundContext()

//test entity is created on anotherContext
let entity: TestEntity = NSEntityDescription.insertNewObject
(forEntityName: String(describing: TestEntity.self),
 into: anotherContext) as! TestEntity
entity.statusCode = "Testing"

//prepare fetch request for test entity
let fetchReq: NSFetchRequest<TestEntity> = TestEntity.fetchRequest()
fetchReq.predicate = NSPredicate(format: "statusCode = %@",
 argumentArray: ["Testing"])

//ensure that entity is not present in mainContext
let entityFromMain = try! mainContext.fetch(fetchReq)
XCTAssertEqual(entityFromMain.count, 0)

//save context that has entity
try! otherContext.save()

//ensure that changes from parent store aren't merged automatically
XCTAssertFalse(mainContext.automaticallyMergesChangesFromParent)

//get inserted entity from mainContext
let entityOnMainAfterSaving = try! mainContext.fetch(fetchReq)

//entity is present in mainContext
XCTAssertTrue(entityOnMainAfterSaving.count > 0)

预期输出 -entityOnMainAfterSaving 不应包含新创建的实体，但它已经存在，尽管 mainContext 未刷新。

更新:我问这个是因为在我的应用程序中存在一种情况:
1.实体的属性在otherContext中被改变
2. otherContext被保存
3.通过viewContext接收实体
4. 属性的值未更新为 p.1 中的状态 (!)

同时，如果在 p.3 中获取之前调用 viewContext.refreshAllObjects()，属性的值将会更新

Answer 1

您似乎混淆了automaticallyMergesChangesFromParent或一般情况下合并上下文与获取。

fetch 将始终访问持久存储，无论上下文是否已与另一个上下文合并。这就是 Core Data 中获取的工作方式。本书中有一个关于“避免获取请求”的部分(https://www.objc.io/books/core-data/)解释了同样的事情。我解释一下:

“The biggest performance offenders are fetch requests. Fetch requests have to traverse the entire Core Data stack. By API contract, a fetch request — even though it originates at the managed object context — will consult the SQLite store in the file system.

Because of this, fetch requests are inherently expensive.”

Excerpt From: Florian Kugler. “Core Data.”

第 25 页的另一个内容，获取请求:

“One important thing we want to point out now is this: every time you execute a fetch request, Core Data goes through the complete Core Data stack, all the way to the file system. By contract, a fetch request is a round trip: from the context, through the persistent store coordinator and the persistent store, down to SQLite, and then all the way back.”

Excerpt From: Florian Kugler. “Core Data.”

这就是为什么即使您关闭了automaticallyMergesChangesFromParent，提取操作仍会从数据库中读取最新值。

2015 年和 2016 年 WWDC 关于 Core Data 的 session 非常好(嗯，它们都是)，我建议您仔细阅读它们。在过去五年左右的时间里，几乎没有六场 session 。我从观看这些 session 中学到了很多东西，因为它们讨论了最佳实践以及多年来添加到核心数据的增量更改。

如果您出于某种原因希望继续查看数据的旧快照(也许您的后台上下文不断添加/删除条目，而您尚未准备好刷新 View 上下文)，那么我建议您查看进入查询生成。它应该给你你想要实现的目标。