Skip to content

Fix move_after placing node one slot too far right (#67) - #121

Open
arancool3000 wants to merge 1 commit into
uralbash:masterfrom
arancool3000:fix/67-move-after-stale-sibling
Open

arancool3000 wants to merge 1 commit into
uralbash:masterfrom
arancool3000:fix/67-move-after-stale-sibling

Conversation

@arancool3000

Copy link
Copy Markdown

What was wrong

In mptt_before_update, the left sibling's lft/rgt are read before mptt_before_delete removes the moving subtree. When the left sibling sits to the right of the moving node in the same tree, that removal shifts it left by the subtree size, but _insert_subtree still used the stale values. The node landed too far right and the tree was corrupted (e.g. moving node 2 after its sibling 4 nested it inside node 7's range).

Fix

Keep the left sibling's primary key alongside its position (for both move_after and the move_before path that resolves a left sibling) and re-read its lft/rgt right after the subtree is removed, just like the parent position is already re-read.

How tested

  • Added test_move_after_right_sibling (moves node 2 after its right sibling 4). It failed before the fix and passes after.
  • Full suite: 297 passed, 1 xfailed (Python 3.12, SQLAlchemy 2.x). flake8 clean.

Fixes #67

AI-assisted (Claude); reviewed before submission.

move_after/move_before captured the left sibling's lft/rgt before
mptt_before_delete shifted it, so a node moved to the right within the
same tree landed one slot too far and corrupted the tree. Fixes uralbash#67.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

move_after moves node too far right

1 participant