jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: About Jackrabbit repository model
Date Thu, 21 Jun 2007 08:14:35 GMT
On 6/21/07, Frédéric Esnault <fesn@legisway.com> wrote:
> > it's not that Jackrabbit "doesn't like it", it's because samename
> > siblings cause a lot of issues from a user perspective (e.g. the path
> > '/a/b[2]' is not stable since it might become
> > '/a/b[1]' if '/a/b[1]' were removed).
> Yes, but as i answered before, the spec only says that the order of same name siblings
must stay consistent, not their exact path. So let's stick to it...like for SQL queries and
joins... ;-)
> > jackrabbit's implementation is optimized for small to medium sized
> > child node sets.
> > performance tests showed that up to ~20k child nodes there's no significant
> > negative performance impact.
> Your performance tests were not made with same name siblings I guess? Because mine,

i tested write performance (adding a node to a parent with many child nodes)
since this suffers with very large child node sets. using samename siblings has
no impact on write performance.

  with 12K same name siblings child nodes, a simple search is awful.
Not a search on something like //lgw:contract[5], which is fast, but
even /jcr:root/lgw:root/lgw:contracts/lgw:contract is an awful
> I agree with Jukka Zitting, a debate on the architectures for which Jackrabbit should
be optimized/made for would be interesting, and I'd be glad to participate to such a talk.

i guess jukka meant that we should first gather a "real life"
requirements/use cases list from user feedback rather than discussing
architectures accommodating theoretical use cases. i agree with jukka.


> cheers
> stefan

View raw message