当使用更复杂的分层模型，对于如何处理级联删除有不同的设置时，很难事先弄清楚delete()与数据库的确切关系。
我找不到任何方法来获取这条信息（“嘿SQLAlchemy，如果我在那边删除那个对象会删除什么？”）来自SQLAlchemy。自己实现这一点似乎并不是一个选择，因为这会在我的预测和delete()的实际结果不同的情况下迟早会产生，这对于用户来说会非常......令人不快。
答案 0 :(得分：0)
我在SQLAlchemy邮件列表上问了这个问题 和Michael Bayer explained the possible options（再次感谢！： - ）：
在刷新之前session.deleted中不存在的唯一删除是由于特定对象是“孤儿”而将发生的删除，以及由于该孤立上的级联而将被删除的对象。
因此，如果不考虑孤儿，session.deleted会告诉您要删除的所有内容。
考虑到孤儿需要在工作单元中遍历所有关系，寻找当前孤儿的对象（有一个API函数可以告诉你 - 如果对象被任何对象视为“孤儿”使用delete-orphan级联引用它的属性，它被认为是“孤儿”），然后遍历那些孤儿的关系，考虑将它们标记为“已删除”，然后再为那些新的规则再次执行所有规则 - 删除的对象。
现在系统由orm / dependency.py实现。通常在会话中逐字地运行一个工作单元并不难，但只是不发出SQL，这会给你最终的刷新计划。但这是一个昂贵的过程，我不想一直打电话。
此处难以添加功能，因为用例不明确。知道什么将被删除基本上需要一半的刷新过程实际进行。但是你已经可以在flush进程本身内部实现事件，最直接的是事件中的before_delete（）和after_delete（），它们将保证捕获所有内容。因此，在你只是进行冲洗并且可能只将事件放入其中之前，基本上运行一半刷新的新功能的基本原理尚不清楚。
我想最大的问题是，“你什么时候打电话给这个”。
一个简单的系统是添加一个新的事件“flush_plan_complete”，它会在整个计划已经组装完成之前，但在任何SQL发生之前将你带入flush（）权限。它可以允许您为活动注册更多对象，然后它将重新运行刷新计划以考虑任何新的更改（因为它现在无论如何都是如此）。如何进行这种注册是很棘手的，因为通常在那里使用Session会很好，但这使得实现起来更加复杂。但是，它可以再次迭代新的更改，并在正常进行之前找到要采取的任何剩余步骤。