NSManagedObjectContext子/父 - 孩子没有删除registeredObjects

我有2个NSManagedObject上下文，一个是临时的，另一个是主要的。临时上下文将其父上下文设置为主上下文。我在下列情况下使用它们：NSManagedObjectContext子/父 - 孩子没有删除registeredObjects

当我创建一个“新”对象时，我用临时上下文创建一个新对象。如果用户点击“取消”并决定不创建新对象，我只需从托管对象上下文中删除对象并保存该上下文。
如果用户保存此新对象，我保存临时上下文，然后保存主上下文以保留这些更改。我使用“performBlock”方法并链接保存，正如Apple和其他Stackoverflow所建议的那样。
如果我正在编辑现有对象，则在编辑期间将其保留在主要上下文中。如果用户点击“取消”，我会在主要上下文中调用“回滚”，从而丢弃所有更改。

在这些情况下，一切似乎工作正常。在保存之后，临时上下文报告它具有0个注册对象，并且主要上下文具有另外的对象。

但是，存在创建“新”对象包括与该新对象具有关系的另一对象的情况。所以对于这个对象，我创建了新的对象，创建了“子对象”，并将其设置在父对象上。所以有2个NSManagedObjects。我以同样的方式执行“保存” - 临时上下文被保存，然后主要被保存。问题是我的临时上下文仍然指出它在保存完成后有2个注册对象。主要对象还声明它有2个，并且它们都正确显示。

我可以通过对临时上下文执行“保存”后对临时上下文执行“重置”来解决此问题。但是，这看起来不正确。为什么我必须这样做？为什么即使在执行保存之后，我的临时上下文仍会报告注册对象？

编辑：我也可以通过执行临时上下文保存后执行“refreshObject：object mergeChanges：NO”对临时上下文的对象来解决此问题。现在看起来像最好的解决方案（直到有人可以解释为什么我需要这样做或为什么会发生这种情况）。我的猜测是这些对象互相引用，导致对象不能释放。

来源

2016-04-29 CoBrA2168

当您在MOC上执行保存操作时，它会将对象保存到持久存储的父MOC。但是物体仍然由MOC保留在记忆中。

默认情况下，托管对象与其上下文之间的引用很弱。这个规则的例外是，一个托管对象上下文维护对任何已更改（插入，删除和更新）对象的强引用，直到提交挂起的事务（具有保存:)或丢弃（具有重置或回滚）为止。

如果您觉得此对象不再需要满足当前未来或生成警报（在存储器中实时运行），您希望通过使用“refreshObject”将每个事件转换为故障来修剪图形对象：object mergeChanges：NO“

来源

2016-04-29 19:01:07 kaushal

看来，执行“refreshObject”或“refreshAllObjects”不会对我的应用程序造成任何不利的副作用。一旦在主要上下文中发生“保存”，我的获取结果控制器将成功通知更改（无论是否刷新临时上下文）。看来，执行刷新是我的最佳选择。 – CoBrA2168

刷新对象，取决于您的陈旧间隔，导致核心数据再次击中商店。调用刷新时会对性能产生影响，因此应谨慎使用。核心数据非常擅长管理自己的内存。只有在遇到实际性能问题时才会参与。 –

还没有真正的性能问题，只是试图阻止它在未来发生。我开始研究这一点，并在使用仪器时更改我的核心数据模型 - 我注意到删除的NSManagedObjects留在内存中。我找不到任何具体的证据或文件表明这是预期的行为。 – CoBrA2168

为什么要考虑注册对象的数量？注册对象只是上下文知道的对象列表。由于该上下文创建了这些对象，所以即使在保存之后，它自然也会继续意识到它们。核心数据在保存后不会清除对象。

给我看，它按预期工作。

来源

2016-04-29 18:16:42

请参阅我不确定这是否是预期的行为。看起来有什么不对的地方在于，即使在对有问题的对象执行“删除”操作之后，临时上下文仍然指出它在内存中具有这些已注册的对象。 – CoBrA2168

是的，之后它会让他们注册一段时间。除非您有特定的理由访问registeredObjects，否则它在日常操作中确实没有多大价值。它有点像'-retainCount'，这听起来有用，但最终对“我们”（非Apple开发者）没有任何价值。 –

NSManagedObjectContext子/父 - 孩子没有删除registeredObjects

回答

相关问题