Defect #547
closed
Malfuction of automatic rebuild of forest index
100%
Description
Scenario: I have an organization "External" and 800 another ones (none of them has descendants). All of them are roots. Then I move the 800 organizations under the External org one by one. The forest index is broken now. When I access organizations tab, the "External" organization doesn't have an arrow (which should indicate the node has some descendants).
Files
Updated by Filip Měšťánek almost 7 years ago
When I manually run rebuild of forest index after that, everything looks ok.
Updated by Radek Tomiška almost 7 years ago
- Assignee changed from Radek Tomiška to Filip Měšťánek
I can't reproduce this issue. When i move some node under other node, forest index is recounted properly.
Could you pls add some additional information about scenario, when issue occurs? Was forest index ok at the start? Maybe some other operation broken him before.
Updated by Filip Měšťánek almost 7 years ago
- File org_after.png org_after.png added
- File org_before.png org_before.png added
- Assignee changed from Filip Měšťánek to Radek Tomiška
The malfunction occurred exactly as I wrote. I have 1000 organizations as root. In a worfklow, I sequentially move 999 organization under one organization. Now the root organization has wrong number in brackets. Don't try to move one organization, but move multiple at once.
For illustration, here is a crop out of the workflow:
def treeType = treeTypeService.getByCode("ORGANIZATIONS");
def roots = treeNodeService.findRoots(treeType.getId(), null);
for (def org : roots) {
try {
if (org.getName() == "Externí") {
continue;
}
LOG.info("Processing org code: [{}] name: [{}]", org.getCode(), org.getName());
TreeNodeFilter filter = new TreeNodeFilter();
filter.setProperty("name");
filter.setValue("Externí");
def treeNodes = treeNodeService.find(filter, null);
org.setParent(treeNodes.iterator().next());
treeNodeService.save(org);
} catch (Exception ex) {
LOG.error("Error during processing org code: [{}] name: [{}]", org.getCode(), org.getName(), ex);
}
}
Updated by Filip Měšťánek almost 7 years ago
And as I wrote before, after I run the RebuildTreeNodeIndexTaskExecutor, the number is corrected.
Updated by Radek Tomiška almost 7 years ago
I was able to reproduce this issue, thx for script. The problem is connected to using loaded forestIndex in tree node instance to recount index => roots list is loaded on the begin and after fist 'save' operation contains outdated indexes.
I'll do appropriate change in index algorithm (additional index read is needed). Workaround could be used now: before org.setParent() refresh org node - org = treeNodeService.get(org.getId()); - see IdmTreeNodeServiceIntegrationTest#testForestIndexAfterBulkMove().
Updated by Radek Tomiška almost 7 years ago
- Status changed from New to Needs feedback
- Assignee changed from Radek Tomiška to Filip Měšťánek
- Target version set to Citrine (7.3.0)
- % Done changed from 0 to 90
I've fixed index algorithm.
Could you do a feedback pls?
Updated by Filip Měšťánek almost 7 years ago
- Assignee changed from Filip Měšťánek to Radek Tomiška
It works now.
Just a remark: I've noticed a slow down of the moving of organizations - for ~1000 orgs it took around 18 mins, which is ~1s per organization.
Updated by Radek Tomiška almost 7 years ago
- Status changed from Needs feedback to Closed
- % Done changed from 90 to 100
Thx for feedback and test.
Additional forest index read was added into algorithm, so it slower, but move operation is noneffective at all, because drops and then create index for whole subtree - https://github.com/bcvsolutions/forest-index - we need to improve this in the future. Now, when algorithm was repaired, then children count is higher in every iteration (subtree is bigger) and slowness is more obvious.