Hi Clay, On Sat, Nov 14, 2015 at 5:46 PM, Clay Ferguson <[email protected]> wrote: > Robert, I don't think any of us, including myself, had a misunderstanding > about the fact that the limitation is for a large number of child nodes > under SAME parent. No one said 50K in the entire repository was causing > problems, but 50K children under same parent IS a problem if it's slow. > It's a very significant issue for actual application developers trying to > build something, because everything looks like its performing great but > will fail miserably when you scale it up. It's hard to call JCR 'enterprise > scale' with such a silly limitation staring is all right in the face > defying any solution.
That may or may not be true - the original post said that 'after 50K plus child nodes retrieval is taking ~15 seconds'. I obviously added a note that this - with the current JCR implementations - is expected. What you consider a limitation is something that I personally consider an implementation constraint - if you want to use JCR it's something that you need to take into account. That being said, Oak is expected to perform much better with flat hierarchies, as long as the child nodes are not sortable. So you might want to try this as well. Just be careful since nt:unstructured does have orderable child nodes so you're better off using something like oak:unstructured. Thanks, Robert
