You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a subtree is deleted, only the root is put into the release pool. This means that if a child node of a deleted subtree is added elsewhere, it will not be resolved from the release pool but instead newly fetched from the database. This newly created update operation conflicts with the delete and fails.
The text was updated successfully, but these errors were encountered:
Add parent to release pool entries. When releasing a subtree, put the root element into the release pool (unparented) and then each child that might be subject to recursive destroy/delete into the release pool (with its parent set)
When you reclaim something from the release pool that has a parent, you blank out the link to that child in the parent’s association cache. This has two effects: (1) if the parent is not reclaimed, then when it's destroyed the child will not be recursively destroyed and (2) if the parent is reclaimed, the already-reclaimed child will not be considered a "previous child", and so will have to try taking it (and fail).
Then after run!, can call destroy on all nodes in the release pool without parent set.
Note we can't skip permissions checks on reclaiming from deleted parents. This could lead to a theft of a child by "release parent; steal child; reclaim parent" (tricky to express, but conceptually possible). More fundamentally, the ability to delete the parent doesn't imply you can operate on its children(?).
When a subtree is deleted, only the root is put into the release pool. This means that if a child node of a deleted subtree is added elsewhere, it will not be resolved from the release pool but instead newly fetched from the database. This newly created update operation conflicts with the delete and fails.
The text was updated successfully, but these errors were encountered: