Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1565988815.1249299194790.JavaMail.jira@brutus>
Date: Mon, 3 Aug 2009 04:33:14 -0700 (PDT)
From: "Thomas Mueller (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-642) Support flat content hierarchies
In-Reply-To: <16816858.1164096481964.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738292#action_12738292 ] 

Thomas Mueller commented on JCR-642:
------------------------------------

I would (try to) use the b-tree data structure: http://en.wikipedia.org/wiki/B-tree

I would keep the internal implementation (PersistenceManagerAPI, NodeState and so on),
but add a property 'hidden' to node (maybe using an empty name). Hidden nodes
would have no properties, only child nodes. When adding a child to a hidden
node X, the child would be added to a child of X, and the b-tree would be 
re-balanced. The same when removing a child from a hidden node. Other than that,
user-facing algorithms would need to be changed, specially getPath, and
NodeIterator. Basically hidden nodes would never be returned to the application and
not be directly accessible using the JCR API.


> Support flat content hierarchies
> --------------------------------
>
>                 Key: JCR-642
>                 URL: https://issues.apache.org/jira/browse/JCR-642
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Jukka Zitting
>
> The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns.
> These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times.  In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node.
> To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.