On 6/21/07, Frédéric Esnault <[EMAIL PROTECTED]> 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
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.
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
cheers
stefan
