-
1. Re: Very slow node delete in 2.8.1
bwallis42 Dec 5, 2014 6:52 AM (in response to bwallis42)Just noted this in the documentation:
If a node with same-name siblings is removed, this decrements by one the indices of all the siblings with indices greater than that of the removed node. In other words, a removal compacts the array of same-name siblings and causes the minimal re-numbering required to maintain the original order but leave no gaps in the numbering.
Would my deleting go somewhat faster if I started with the highest possible numbered node? i.e. the node where Node.getIndex() has the highest value?
-
2. Re: Very slow node delete in 2.8.1
rhauch Dec 5, 2014 12:23 PM (in response to bwallis42)1 of 1 people found this helpfulWhen possible, delete child nodes that are at the end of the list of children. For child nodes that have the same name (e.g., are same name siblings), deleting any node but the last SNS will be expensive, since all SNS following the removed node have to be updated.
(This behavior in 3.x and 4.x is much improved, since SNS indexes are computed on the fly rather than managed.)
-
3. Re: Very slow node delete in 2.8.1
bwallis42 Dec 5, 2014 4:57 PM (in response to rhauch)Thanks Randall for confirming what I suspected after reading the doco on the remove function. We will try re-ordering our delete operations.
-
4. Re: Very slow node delete in 2.8.1
bwallis42 Dec 6, 2014 5:23 AM (in response to rhauch)Is it possible to order the results of a query by the SNS index and descending? I've been reading about the queries in the JCR but cannot see how to do this since the index doesn't seem to be available as a property on the nodes.
thanks.
-
5. Re: Very slow node delete in 2.8.1
rhauch Dec 8, 2014 11:34 AM (in response to bwallis42)We expose the SNS index as a pseudocolumn, so at the moment there is no way to order by SNS index. However, you can order by 'jcr:name', as this pseudocolumn contains the local part and SNS index (if there is one).
-
6. Re: Very slow node delete in 2.8.1
bwallis42 Dec 11, 2014 7:05 AM (in response to bwallis42)1 of 1 people found this helpfulWe have successfully run our node deletions.
We found that if we delete 100 nodes and then do a save() it only takes about 2-3 times longer than deleting one node and the time decreased as we deleted more. So we are down from something like 2800 nodes to about 150 and performance is back to normal.
Deleting from the highest numbered node did not seem to help with the performance.