You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2013/11/13 11:05:23 UTC

[jira] [Commented] (OAK-1172) AbstractTree.getChildrenCount() not very performant due to INTERNAL_NODE_NAMES

    [ https://issues.apache.org/jira/browse/OAK-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821145#comment-13821145 ] 

angela commented on OAK-1172:
-----------------------------

the current code is troublesome in many ways:

1. we don't have a consistent handling of filtering out the hidden items
2. the code checks if there are hidden child nodes even if the total size of child nodes is 0
3. SecureNodeBuilder#hasChildNode *always* calculates the tree permissions even if no child exists with the specified name

2 and 3 can IMO be optimized very easily. for 1 we need a more detailed discussion on how and where to filter out the hidden items.

> AbstractTree.getChildrenCount() not very performant due to INTERNAL_NODE_NAMES
> ------------------------------------------------------------------------------
>
>                 Key: OAK-1172
>                 URL: https://issues.apache.org/jira/browse/OAK-1172
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>            Reporter: Tobias Bocanegra
>
> the AbstractTree.getChildrenCount() does unnecessary checks for hidden names:
> {code}
>         long count = nodeBuilder.getChildNodeCount(max);
>         for (String name : INTERNAL_NODE_NAMES) {
>             if (nodeBuilder.hasChildNode(name)) {
>                 count--;
>             }
>         }
> {code}
> this is not optimal, especially because the nodebuilder creates child builders:
> {code}
>     public boolean hasChildNode(@Nonnull String name) {
>         return getChildNode(name).exists();
>     }
> {code}
> Suggest: to extend the NodeBuilder.getChildNodeCount() method to accept an additional flag if to include hidden nodes or not.



--
This message was sent by Atlassian JIRA
(v6.1#6144)