[
https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738323#action_12738323
]
Stefan Guggisberg commented on JCR-642:
---------------------------------------
@bart;
> Would it be an idea to store the hierarchical information in a separate table
> with only (node_id, parent_id)?
yes, that would be the obvious approach for db-based pm's.
some random thoughts:
- you'd need a 3rd column ('name')
- you'd need a 4rd column (e.g. 'pos', in order to support ordered child nodes)
- read performance would suffer, especially for remote db's (2+ instead of 1 db
access)
- write performance would suffer (updating/reorganizing indices of very large
tables
can be very expensive)
- same-name sibling support would be a challenge (both implementation and
performance-wise)
- Node.hasNode() e.g. would be significantly slower
> 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.
