Modifying Organizations casuses re-calculations of entire tree

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 6.0.12 EE, 6.1.0 CE RC1
• Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1
• Component/s: Performance, WCM > Sites Management > My Sites
• Labels: None

The reason it was still taking a long time is because of the re-calculation of the left and right organization ids on the entire tree. The pattern is based on the "nested set" algorithm for encoding nodes in a tree so that you can quickly locate all children.

I've replaced that pattern with one that provides the same feature, but doesn't have the cost of having to re-calculate the entire tree. Plus there is zero cost on deletes or adds. The only cost comes when an org has children. However, unlike the nested set algorithm that causes all adjacent nodes and all descendants of the current and adjacent nodes to require re-calculation, only the current node and all of it's descendant nodes need to be re-calculated.

i.e. When updating a leaf node, only that node needs to be updated. As you go up the tree, only nodes in the subtree need to be updated.

[Kiyoshi Lee]

PASSED Manual Testing using the following steps:

1. Deploy Make-Data portlet
2. Create 7,000 organizations
3. Observe time elapsed between creation of organizations
4. Prior to fix 400 organizations were created in the time it took to create 7000 after the fix (see attachment)

Note: In earlier versions adding a child organization causes the entire company search index to re-index, which increases in time as more and more organizations are created.

Reproduced on:
Tomcat 7.0.21 + MySQL 5. 6.1.x Revision: 91473.

Fixed on:
Tomcat 7.0.21 + MySQL 5. 6.1.x Revision: 91671.

[JR Houn]

Kiyoshi - please close this ticket once you've completed regression testing. Thanks!
-jr

[Vicki Tsang (Inactive)]

This is being bulk closed in preparation for the new workflow.