Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.146.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=x6Yes4PcJqO7RG7Z6g/p1CP8p31oYxJjEMgIdzJ51QtnoZ/3M6WXAM9WgIMix1NfGJyuTT8Jv+PU0w2ofywZx4W4B/dWOEBIT0GZyOzMTj2cG0U87XL6+3qERYc3K96xET0hEvvPnsPDDlodGYpKqjm9L9WHdxFbvLHe79TTa4I=
Message-ID: <90a8d1c00805280523h1dfb2de7h80ff46b2d46f1833@mail.gmail.com>
Date: Wed, 28 May 2008 14:23:49 +0200
From: "Stefan Guggisberg" <stefan.guggisberg@day.com>
Reply-To: stefan.guggisberg@day.com
Sender: stefan.guggisberg@gmail.com
To: users@jackrabbit.apache.org
Subject: Re: importXML() fails with a ConstraintViolationException
In-Reply-To: <1761221336.20080528141621@holeczek.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <006b01c8c004$29e5fe40$4801a8c0@pessac.v4x.com>
	 <510143ac0805270758s7e265634l5dbd6c5e7e7b06d7@mail.gmail.com>
	 <007b01c8c013$c6967580$4801a8c0@pessac.v4x.com>
	 <c3ac3bad0805280113u79cef7a0s542fc061dbd784ac@mail.gmail.com>
	 <1761221336.20080528141621@holeczek.de>

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).

cheers
stefan

>
> Regards,
>  Florian
>