| Issue 1: | Reparenting | |
| 2 people starred this issue and may be notified of changes. | Back to list |
Currently, MPTT fields are only maintained automatically when a `Model` instance is created or deleted. If an instance's parent is changed, perform the appropriate steps to reparent it within the tree structure. Ideally, we'd like to avoid incurring an extra database query on each save to check if an instance's parent has been changed. This isn't a showstopper, as MPTT is generally more suited to data which is read heavy and infrequently updated, such as trees of categories. Django ticket [http://code.djangoproject.com/ticket/4102 #4102 - Allow UPDATE of only specific fields in model.save()] involves tracking changes to instance fields, so keep an eye on it.
Dec 29, 2007
Project Member
#1
jonathan.buchanan
Labels:
Milestone-Release0.1
Dec 30, 2007
Started this feature by implementing sub node to root node reparenting in revision 5. Show your working out for full marks - http://django-mptt.googlecode.com/svn/trunk/NOTES ;)
Status:
Started
Labels: -Priority-Medium Priority-Critical
Dec 31, 2007
Implemented root node to child node reparenting in revision 7.
Dec 31, 2007
Implemented reparenting when a child node is assigned a parent in a different tree, in revision 11. A refactor to extract functions for common tree modification queries looms large.
Jan 1, 2008
Implemented some butt-ugly reparenting when a child node is assigned a different parent in the same tree, in revision 12. Refactor time.
Jan 2, 2008
Code created for the different automatic reparenting scenarios has now been extracted out into methods in TreeManager. According to the tests, automatic reparenting now works, but I'll give the tires a good kicking with the Admin and a view which displays the current tree before I mark this one as fixed. All the node moving methods which were added to TreeManager as a result of this feature always make the node which is being moved the last child of its new parent - these should be a good base for future work to allow us to move a node to any position within a tree.
Jan 2, 2008
I've just given the current node movement TreeManager methods a good old refactoring to reduce the number of queries required to perform node movement - none of the currently implemented move operations need any more than 2 queries to get the job done. I've tried an MPTT model out in the Admin, where you only have the parent field to work with - automatic management of tree fields when the parent is changed seems to work as expected.
Status:
Fixed
|