I was unaware simply making nodes unorderable would allow good scalability. Good to know! I guess we could always experiment with using a nextNode property to allow iterating in order, and also get good scalability for inserting/deleting, but using that linked-list approach would be slow at iterating, because each node retrieved would have to come from a lookup of it's nextNode property. The only thing (afaik) that could significantly improve that performance would be if each node's children happened to be in contiguous storage so that disk caching at hardware layer played a role in the speedup.
Is using this nextNode (linked list built on Node properties) the best practice for when ordering AND large numbers of children are an absolute requirement? What do you guys think? Crazy idea or reasonable? -Clay On Sun, Aug 6, 2017 at 11:15 PM, Chetan Mehrotra <[email protected]> wrote: > > Every addition of a child node implies a change to the parent node > Document > > Looks like the parent nodetype is nt:unstructured which requires > orderable children. If you do not require that use a nodetype like > oak:Unstructured. See [1] for some background > > Chetan Mehrotra > [1] https://jackrabbit.apache.org/oak/docs/dos_and_donts.html#La > rge_number_of_direct_child_node > >
