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)