You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2014/07/03 19:55:34 UTC
[jira] [Moved] (JCRVLT-53) vlt: with many child nodes,
NodeNameList.restoreOrder is very slow with Oak
[ https://issues.apache.org/jira/browse/JCRVLT-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tobias Bocanegra moved JCR-3793 to JCRVLT-53:
---------------------------------------------
Key: JCRVLT-53 (was: JCR-3793)
Project: Jackrabbit FileVault (was: Jackrabbit Content Repository)
> vlt: with many child nodes, NodeNameList.restoreOrder is very slow with Oak
> ---------------------------------------------------------------------------
>
> Key: JCRVLT-53
> URL: https://issues.apache.org/jira/browse/JCRVLT-53
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Attachments: JCR-3793.patch, ReorderTest.java
>
>
> The method org.apache.jackrabbit.vault.fs.api.NodeNameList.restoreOrder re-orders orderable child nodes by using Node.orderBefore. This is very slow if there are many child nodes, specially with Oak (minutes for 10'000 nodes, while only about 1 second for Jackrabbit 2.x).
> [~tripod], I wonder if a possible solution is to first check whether re-ordering is needed? For example using:
> {noformat}
> boolean isOrdered(ArrayList<String> names, Node parent)
> throws RepositoryException {
> NodeIterator it1 = parent.getNodes();
> for (Iterator<String> it2 = names.iterator(); it2.hasNext();) {
> if (!it1.hasNext() || !it1.nextNode().getName().equals(it2.next())) {
> return false;
> }
> }
> return !it1.hasNext();
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)