jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@day.com>
Subject Re: importXML() fails with a ConstraintViolationException
Date Wed, 28 May 2008 12:23:49 GMT
On Wed, May 28, 2008 at 2:16 PM, Florian Holeczek <florian@holeczek.de> wrote:
> Hallo Alexander,
>> An effective content model tries to reduce the number of nodes (XML
>> imports tend to create lots of nodes with a single property at the
>> leaf) and has a high properties/nodes ratio: something around 10 is
>> good (ie. 10 times more properties than nodes). This is especially
>> true if you use a bundle persistence manager (which you should ;-)),
>> because it reads/writes bundles that consist of a node and all its
>> properties (except for larger binary properties that will go into
>> the DataStore, if configured).
>> Having flat hierarchies ("repository in width") is not efficient,
>> since Jackrabbit has a limitation when you have many child nodes (>
>> 1000) under one node - it will be quite slow then. In favor of human
>> explorability one should avoid that anyway, since it is easier when
>> the content is structured, eg. by date (/2008/april/*), so that only a
>> few children are visible at each level.
> Thanks for pointing this out!
> Is this documented somewhere or just internal developer knowledge?

it has been discussed on the list repeatedly.

> Is it for reasons of the JCR concept / API or due to restrictions of
> the Jackrabbit implementation?

there's no hard-coded limit for the # of child nodes per node. the current
design is optimized for small to medium sized child node sets, i.e. up to
~10k child nodes per node. really large child node sets negatively affect
write performance (in the current design).


> Regards,
>  Florian

View raw message