jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Esnault <f...@legisway.com>
Subject RE: About Jackrabbit repository model
Date Thu, 21 Jun 2007 08:01:02 GMT
> 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, 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 query....

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.


View raw message