On Wed, Feb 17, 2010 at 5:17 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Hi, > > This one's a quite frequently asked feature. Currently we store the > full list of child nodes in the same bundle or node state record with > the parent node. This makes it expensive to support nodes with large > amounts (>>1k) of child nodes.
in my experience notable write-performance impacts start with >>10-20k child nodes ;) 10-20k is quite a lot IMO, most applications probably won't ever hit this 'limit'. i agree that flat hierarchies is an important feature, however we shouldn't compromise the performance for the 'standard' case with less than 1k child nodes just for the sake of supporting flat hierarchies. after all, the JCR api is inherently hierarchic. maybe we should provide separate node types or node type attributes to indicate that instances of that type may have a large number of child nodes. nodes of that node type would be represented/handled differently in the persistence layer. cheers stefan > > The obvious solution to this problem is to use a data structure like a > B-tree to keep track of the child node entries. Doing this efficiently > while still supporting both orderable nodes and same-name-siblings > (i.e. nt:unstructured) probably requires some deeper thought. An added > benefit would be the ability to do this on top of an append-only > storage model. > > Any other ideas on how we could do this? > > BR, > > Jukka Zitting >
