Coredata安全明确的subEntities

Question

我想要一个安全的方法来清除coredata中的subEntities。

我有这样的多对多关系：Product *<->* Product。因此，我必须创建一个subEntity来保存（sortPosition，groupName .....）之间的一些特殊值。

所以就像这样：Product *<->1 ProductSubEntity 1<->*Product。

当我从服务器的API下载产品时，正确更新的最简单方法对应于服务器的结果：

1. 删除所有子关系（[self removeProductSubEntities:self.subEntities]）。
2. 从服务器的结果中添加sub。

结果：coredata中存在很多subEntity（不会与任何产品保持关系），这可能会在CRUD（我认为？）时占用存储/内存/ cpu。但我无法实际删除subEntity（如果它在某处保持对viewController的Object的引用，它可能会导致崩溃：访问已删除的对象）。

问题：

如果符合以下情况，我如何清除这些子实体（有时可能会出现）：

1. 与任何产品无关。
2. 从任何地方（任何viewControllers或对象）都没有实际引用???
P / S：我想在终止应用时实现批量删除。这可以考虑一个安全的解决方案吗？

Answer 1

我不认为这是数据存储问题，而是UI更新问题。当您不再需要它们时，应该从数据存储中删除对象，并且应该相应地更新UI。

你没有提到的一件事是重复使用。您的下载可能是现有项目的更新，您可以找到并更新，然后生活很容易。可以说下面的所有内容在这种情况下仍然适用，但因为您的UI可能不会更新以反映更改，您可能需要刷新托管对象。

对于UI更新，通常明智地观察数据存储区的变化，通常使用NSFetchedResultsController。如果您这样做，那么您的UI会自动更新自己。

如果您明确地传递实体实例，那么您应该有一些方法可以明确地触发更新，具体如何工作取决于您的UI。一般来说，您会做一些事情，比如发布UINotification来告诉系统数据存储区已更改，并且需要重新验证其数据对象。对于UI，您不应该向用户显示现在已死的对象，并且在您的问题中，您谈到不删除以避免崩溃，允许用户更新无效对象并且只是静静地不告诉他们他们的更新将不会保存。收到通知后，您可能希望从堆栈中弹出（某些）控制器，或重新查询数据存储区以显示新数据。

如果由于某种原因您不想执行上述操作，那么是的，您可以查询所有具有nil关系的实体，然后批量删除它们。这应该在后台线程上完成，就像数据加载一样，我建议在app load而不是close上执行它（因为你不会加载那么多的视图控制器，而且现在都应该只有有效的引用。 ..）。