> 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. cheers stefan
