NSManagedObject prepareForDeletion中self.managedObjectContext == nil的重点是什么？

Question

我有一个Reminder实体，只要删除某个实体B，就需要更新其date属性。我花了几天编写思考我可以在删除时在托管对象子类中做一些有用的事情。我试过了

- (void)willSave
{
if (self.isDeleted) 
    // use self.managedObjectContext
}

背景是零。那里的关系也被拆除了。很公平。

所以...我开始为prepareForDeletion编写繁琐的代码来规避对象尚未被删除的事实，但随后Core Data会在我的脸上抛出self.managedObjectContext == nil。文档说这是我在“关系被拆除之前”所做的事情。那么self.managedObjectContext == nil如果self.relationshipA.managedObjectContext可以访问（正如文档建议的话）那么有什么意义呢？更重要的是，为什么我尚未删除的对象没有其上下文？

我读了关于该问题的评论here

  

它不是'错误'，因为它是'disown'，上下文已经不同意你的对象（他被删除并且保存被提交到数据库），所以你的对象被剥夺了。不要保存在正在更改的对象和对象中，因为无论如何都应该在操作之后提交/保存保存。 - Dan Shelly 5月21日19:05

我的代码是：

[moc deleteObject:obj]
[moc save:NULL]

当我删除保存操作时，self.managedObjectContext中存在prepareForDeletion。也就是说，直到自动保存，再次为零。可能是因为父上下文也删除了它，然后是UIManagedDocument的保存。

我开始认为我唯一的选择是制作一个自定义删除方法（直到Core Data级联删除，在这种情况下它不会被调用），或者创建一个新类来监听NSManagedObjectContextDidSaveNotification

更新

用户希望与某个人保持联系，并且如果没有联系，则希望在一定时间间隔（存储在ContactWish中）后提醒。我想要完成的是，当删除某个人的最新ContactOccasion时，相应的场合 - ＆gt; person-＆gt; wish-＆gt;提醒会被更新（使用间隔）。

由于这对我来说是一次学习经历，我想找到正确的方法（可以使用级联删除等），而不只是从我的代码中的每个地方手动调用更新{{1} }。欢迎提出建议。

（提醒实体也已准备好更多手动使用）

Answer 1

让Reminder实体管理其日期属性会不会更合乎逻辑？它可以“监听”（可能通过changedValues:）到其被删除的关系实体并执行更新。

这似乎更加一致，因为B实体不应该真正关注Reminder实体更新的逻辑。

修改
根据下面的讨论并基于我的观点，您无法使用更新逻辑加载数据库级联删除模型：

您可以引入您设置和收听的属性，而不是对删除作出反应，以便进行更改。

我真的不知道如何依靠核心数据删除机制比编写处理此逻辑的“deleteOccasion”方法更容易或更优雅。