On Sat, Nov 14, 2015 at 9:23 PM, David Marginian <[email protected]> wrote: > Thanks Robert. I considered moving to Oak, but the system was originally > designed using JackRabbit and I recently discovered this limitation doing > load/performance testing for a future requirement. Moving to Oak now would > be too large of a change for us to take on now. Back to JackRabbit, is > there documentation somewhere on the different node types and which are > ordered or not?
Note that Jackrabbit has the child nodes limitation irrespective on whether they are orderable or not. As for the node types, the JCR spec would be a good start, see section 3.7.11 Standard Application Node Types http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.11%20Standard%20Application%20Node%20Types Robert > I don't need ordered nodes but I can't find documentation > talking about the nodes and which are ordered (currently using nt:folder). > > > On 11/14/2015 12:17 PM, Robert Munteanu wrote: >> >> 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 >> >
