Hi abing and all,
On Jan 3, 12:50 pm, "Nimrod A. Abing" <[EMAIL PROTECTED]> wrote: <snip>
Will this be available on the 1.2 or 1.1 branch or both?
I assume 1.2 only. <snip>
http://www.sitepoint.com/print/hierarchical-data-database
I maintain that recursion isn't necessary to display MPTT tables. Anything that is recursive or converts MPTT tables to nested arrays is not exactly using the benefits that the DB structure offers ;).
For inserts, I am talking about inserting a single new node in an arbitrary parent. For example, inserting a new node under Meat, say Chicken. I want to insert it so that it goes in between Beef and Pork. i.e., We end up with Beef, Chicken, Pork under Meat.
The logic necessary to add a new node in the middle of it's siblings isn't very different from adding a new node and then reordering. The minimum executed sql is about the same as creating alone - slightly different ofsets. <snip>
For reordering, I am talking about moving a node within its subtree changing its left to right order. In the example above, say I change my mind and switch Beef and Pork so that we end up with Pork, Chicken, Beef.
This is what I have currently developed and am testing in the MPTT behaviour.
For deletes, when I delete a non-leaf node, all of its children will be reparented to the immediate parent of their parent.
<snip>
Delete does not seem to work as I expected in the aros example. I get the message "aro Daniele (and any child aros) deleted." This does not conform to my requirement that its child nodes be reparented to their grandparent. What I need is akin to a child being orphaned and sent to their grandparents when their parents die. Though deleting the children of a node makes much more sense when we are talking about filesystems.
I have never heard of or considered this case. Why would you want to do that exactly? It seems perfectly logical to me that if you delete a node you also want to delete it's children. But in any case, the sql to do what you have explained isn't much different than deleting a node and all children (would just need to delete the node, re-index the children -1, the 'new' parent right field -2 and all subsequent nodes -2.) I just don't understand why you would want to. <snip>
Comments are very much welcome. Though at this stage, I am thinking of rewriting the whole thing to use the implementation described here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/461776
Adding redundancy like that will make some tasks simpler but I wouldn't expect it to help with any of the problems that having large tables would cause. But variety is what spawns new ideas so if you go that route I'd be interested to see what you come up with ;). HTH, AD7six Please note: The manual/bakery is a good place to start any quest for info. The cake search (at the time of writing) erroneously reports less/no results for the google group. The wiki may contain incorrect info - read at your own risk (it's mainly user submitted) :) You may get your answer quicker by asking on the IRC Channel (you can access it with just a browser here:http://irc.cakephp.org). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
