ios5 – 核心数据 – 保留父上下文的保留周期

前端之家收集整理的这篇文章主要介绍了ios5 – 核心数据 – 保留父上下文的保留周期前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
假设我们在核心数据模型中有两个实体:部门和员工.
该部门与员工有一对多的关系.

我有以下ManagedObjectContexts:
– 根:连接到持久商店协调员
– 主:与父根的上下文

当我想创建一个员工时,我会做以下事情:
– 我在主要环境中有一个部门
– 我在主要上下文中创建一个Employee
– 我将部门指派给员工部门财产
– 我保存主上下文
– 我保存根上下文

这将在主上下文和根上下文中创建一个保留循环.

如果我没有一个子上下文(全部在根上下文中),那么我可以通过在Employee上调用refreshObject:mergeChanges来打破保留周期.在我的情况下,我仍然可以使用这种方法来打破主要环境中的循环,但是我将如何打破根环境中的循环?

旁注:这是一个简单的例子来描述我的问题.在仪器中,我可以清楚地看到分配数量的增长.在我的应用程序中,我有一个深度超过一个级别的上下文,导致更大的问题,因为我得到一个新的实体分配与保留循环每个上下文我正在保存.

更新15/04:NSPrivateQueueConcurrencyType与NSMainQueueConcurrencyType
在保存两个上下文之后,我可以使用Department对象在Main上下文中执行refreshObject:mergeChanges.如预期的那样,这将重新纠正该部门的对象,打破保留周期,并释放部门和员工实体.

下一步是打破根语境中存在的保留循环(保存主上下文已将实体传播到根上下文).我可以在这里做同样的技巧,并使用Department对象在Root上下文中使用refreshObject:mergeChanges.

奇怪的是:当我的根上下文使用NSMainQueueConcurrencyType创建(所有分配都被重新发现和处理),但是当我的根上下文是使用NSPrivateQueueConcurrencyType创建的(所有分配被重新错误但不被处理) ).

旁注:根本上下文的所有操作都在一个performBlock(AndWait)调用中完成

更新15/04:第2部分
当我做另一个(没用,因为没有变化)使用NSPrivateQueueConcurrencyType在Root上下文保存或回滚时,对象似乎被释放.我不明白为什么这与NSMainQueueConcurrencyType不同.

更新16/04:演示项目
我创建了一个演示项目:http://codegazer.com/code/CoreDataTest.zip

更新21/04:到达那里
谢谢Jody Hagings的帮助!
我试图从我的ManagedObject didSave方法移动refreshObject:mergeChanges.

你可以向我解释一下:

[rootContext performBlock:^{
    [rootContext save:nil];
    for (NSManagedObject *mo in rootContext.registeredObjects)
        [rootContext refreshObject:mo mergeChanges:NO];
}];

[rootContext performBlock:^{
    [rootContext save:nil];
    [rootContext performBlock:^{
        for (NSManagedObject *mo in rootContext.registeredObjects)
            [rootContext refreshObject:mo mergeChanges:NO];
    }];
}];

最上面的一个不会释放对象,最下面的一个.

@R_403_323@

我看了你的示例项目.发贴的Kudos.

首先,你看到的行为不是一个错误…至少不在核心数据.如你所知,关系导致保留周期,必须手动破坏(记录在这里:https://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/CoreData/Articles/cdMemory.html).

你的代码是在doSave中执行的.可能会有更好的地方打破周期,但这是一个不同的事情.

请注意,您可以通过查看registeredObjects属性来轻松查看MOC中注册的对象.

但是,您的示例将永远不会在根上下文中释放引用,因为在该MOC中从不调用processPendingEvents.因此,MOC中的注册对象将永远不会被释放.

核心数据有一个概念叫做“用户事件”.默认情况下,“用户事件”正确包装在主运行循环中.

但是,对于不在主线程上的MOC,您有责任确保正确处理用户事件.请参阅本文档:http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/CoreData/Articles/cdConcurrency.html,特别是使用通知的其他线程中跟踪更改的部分的最后一段.

当你调用performBlock时,你给它的块被包装在一个完整的用户事件中.但是,对于performBlockAndWait来说并不是这样.因此,私有上下文MOC将把这些对象保留在其registeredObjects集合中,直到调用processPendingChanges.

在您的示例中,如果您在performBlockAndWait中调用processPendingChanges或将其更改为performBlock,则可以看到发布的对象.这两者之一将确保MOC完成当前用户事件并从已注册的对象集合中删除对象.

编辑

回应你的编辑…这不是第一个不会释放对象.这是MOC仍然有注册为故障的对象.这是在保存之后发生的,在同一个事件中.如果你简单地发出一个无操作块[context performBlock:^ {}],你会看到从MOC中删除的对象.

因此,您不需要担心,因为在该MOC的下一个操作中,对象将被清除.你不应该有一个长期运行的背景MOC,无论如何,所以这真的不应该是一个大问题.

一般来说,你不想只是刷新所有的对象.但是,如果您想要在保存后删除所有对象,那么您在doSave中执行此操作的原始概念是合理的,因为在保存过程中会发生这种情况.但是,这将会在所有上下文中(您可能不想要的)中的对象发生故障.你可能只想在背景MOC中使用这种恶劣的方法.您可以在didSave中检查object.managedObjectContext:但这不是一个好主意.更好的是为DidSave通知安装一个处理程序…

id observer = [[NSNotificationCenter defaultCenter]
    addObserverForName:NSManagedObjectContextDidSaveNotification
                object:rootContext
                 queue:nil
            usingBlock:^(NSNotification *note) {
    for (NSManagedObject *mo in rootContext.registeredObjects) {
        [rootContext refreshObject:mo mergeChanges:NO];
    }
}];

你会看到,这可能会给你你想要的…虽然只有你可以确定你真正想要完成的事情.

猜你在找的iOS相关文章