jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger" <Felix.Meschber...@day.com>
Subject Re: About Jackrabbit repository model
Date Thu, 21 Jun 2007 07:17:40 GMT
Hi Frédéric,

-          Jackrabbit doesn't like same name siblings, so it would be better
> to give nodes specific names;

The problem with same name siblings is two-fold: One is the implementation
inside Jackrabbit and one is the specification.

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.

AFAIK, inside Jackrabbit same name sibblings result in an additional
indirection to handle the list of nodes with the same name.

-          Jackrabbit doesn't like too many child nodes under on same nodes
> (ie. 1000 or more child nodes for one parent node)

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. But it is true the more child nodes you have on a single parent
node, the more performance will suffer and the more memory consuming
Jackrabbit will be.

Your main issue is using same name siblings. (Did I already say, I don't
like them ? :-) )

But I don't think my repository structure is unique.

While the JCR API is intended to also support such flat hierarchies, it is
really the support for higher level hierarchies, which makes the API unique.
And this is also at the bottom of the Jackrabbit implementation: Flat
hierarchies have only been a side goal of the design.

It seems that searching one this kind of architecture takes ages, I made a
> search yesterday that I stopped after 25 minutes.
> /jcr:root/lgw:root/lgw:contracts/lgw:contract/jcr:deref(@lgw:internalContractor,
> 'lgw:contractorType')[@lgw:companyName='Legisway']

I agree, that 25 minutes is not acceptable. I cannot tell for sure, what the
problem here is, but I assume it is all linked together: flat hierarchy and
a query which seems to be expensive to handle - I could assume that the
jcr:deref function might have quite a high cost.

I think is quite common)?

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message