Dirk, There are probably only a hand-full of core JCR (Jackrabbit) developers who fully understand why this technical limitation exists, and I would argue that most of them would fix this if they ever started over from scratch. Just imagine how much harder it is now for someone to convert an existing RDBMS over to JCR. In such a conversion, the obvious thing to do is let each RDB table become a parent node and contain all the children from the table of the same "type". But even this most basic architectural pattern fails at 50K records? Uh, that's a fail. If this is an impossible problem to solve for some kind of technical reason, that's one thing, but when people try to explain it away as a "feature" rather than a "bug", I just don't buy a word of it. -Clay
On Sat, Nov 14, 2015 at 11:22 AM, Dirk Rudolph <[email protected]> wrote: > The whole discussion about large number of siblings is kind of off topic. > > I would answer: as everything performs better when it's optimized and the > common use case of jackrabbit is to store hierarchical data, choose another > data store if you want to store flat data. Same for RDBMS. They are not > designed for hierarchical data and implementing this use case has a > drawback there as well as implementing large flat data for jackrabbit. > > The question and my last off topic comment to the discussion is: is it a) > worth the effort and b) do we really want the drawbacks? > > At the end the original topic should perform well with some hierarchy. If > not jackrabbit may not be the best to store those kind of data. > > Cheers, D > >
