> For example, consider a node /A with 5 children named B. You would access > the first as /A/B[0] the second as /A/B[1] and so forth. If you now decide > to delete the second one (B[1]) the indices of all same name siblings whose > index is larger than 1 will change. So B[2] becomes B[1], B[3] becomes B[2] > and B[4] becomes B[3]. IMHO this is problematic and this is why I never use > same name siblings.
I agree on this, but this is not a problem. Spec (section 4.3.1, if I don't make mistake) states that same name siblings order must be consistent. Which meanse whatever you do, even if you remove a node, the order remains the same, which is the most important to me. And basically I don't think you'll access a specific nodes with its position, but more likely with a predicate on a property value. > This is purely an issue of the current implementation of node states. But, > honestly, I do not think the critical limit is already at 1000 child nodes, > this number should be much higher - of course not considering same name > siblings. Of course, 1000 was just a random number, not an evalutation of Jackrabbit limitations. But my problem here is that I need both : many child nodes being same name siblings ;) > Your main issue is using same name siblings. (Did I already say, I don't > like them ? :-) ) Yes I got that. > I tend to think, that not everything which is "quite common" is also "good" > by definition. Don't get me wrong here, I do not want to say, your > architecture is bad. But it seems that the architecture does not cope well > with the current implementation of Jackrabbit. I agree on this, even if many people do the same thing does not mean they are not doing a mistake, you're perfectly right, but for software requirements, if most users want to use a certain architecture (or whatever), it actually should become a requirement for the software, imo (and not only my opinion, I guess). Can you come with a more Jackrabbit-friendly architecture to deal with my contracts/contractors/contacts architecture, or the book/author/comments we read on this mailing list? Frederic Esnault
