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 07:32:04 GMT


> 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

Mime
View raw message