删除一个大型文档子树仍然会对每个子节点发出一次更新

• 这个问题存在吗?

• 我搜索了现有的问题

QQ 这与配置大纲无关

• 这个问题与自我接待配置无关

当前的行为

删除文档也会软删除其所有后人. 当文档有大型子树时,删除请求可能会在操作完成前超时或返回网关错误.

子树在一个递归式查询中解决了,但后人被一次装入并被摧毁一个. 因此,有 N 子树仍然在请求交易中执行 N 软删除更新 。

如果达到请求或数据库超时,则交易会回滚并保持文档未被删除.

• 预期行为

删除有大量后人的文件,应当完成,且不能超过请求的超时,或者发布每个后人一次更新.

1. 创建或导入有大量后代的文件。
2. 删除根文档。
3. 观察删除请求的期限和数据库查询。
4. 如果子树足够大, 请求时间会超出或返回网关错误 。

环境

• 大纲:目前的 " 主要 "
• 数据库:PostgreSQL

还有别的吗?

#13311将树下取景减少为递归式查询,但有意保留个人的"Destroy ()"电话,以便每个后代的模型钩跑.

这就留下了剩下的软删除更新作为仍然能与后代数量相适应的部分. 以批量更新取代它们将解决查询数,但也会跳过实例级的破坏钩. #13484目前依靠其中一个钩来记录"被删除的ById".

我可以看到的替代办法是:

• 分批更新后代,并明确保留必要的删除字段。
• 保持现有的破坏行为,但处理后代同步的分批处理。
• 将大宗数据库更新与每个文件的可重试副作用分开。

在准备修改之前, 我先讨论这个问题, 因为适当的修补取决于删除周期行为需要保持同步.