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 jukka.zitting@gmail.com
 designates 209.85.162.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=dkSViJ2wCPiKNx5DYSWEV92B900gIFdoT+gzd+dS8DViV18CGdWcLQNspKVLaFIx1LEXR2pP53Fph6VzWnARjG0d69KpYXTRzyZTvww/2dDf02lv1LcrOtQ4vDZf+m4j81Nw+qMp7BSA6ZEPiGBnjqMvhmnjtVnItuBtlhtJA80=
Message-ID: <510143ac0711051435p7200af80mbbea90d70a489623@mail.gmail.com>
Date: Tue, 6 Nov 2007 00:35:38 +0200
From: "Jukka Zitting" <jukka.zitting@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Enforcing constraints; Sessions and Threading
In-Reply-To: <472F94B3.3000203@mulesource.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <472F5158.9080407@mulesource.com>
	 <510143ac0711051312j6cffc05br81f284724d9eea9a@mail.gmail.com>
	 <472F8E4B.4010001@mulesource.com>
	 <510143ac0711051351i20a03092n39fc3623548c1953@mail.gmail.com>
	 <472F94B3.3000203@mulesource.com>

Hi,

On 11/6/07, Dan Diephouse <dan.diephouse@mulesource.com> wrote:
> Jukka Zitting wrote:
> > There's an added benefit if you plan to use the "resource name" as a
> > primary identifier for the entries, as you'll then be able to use
> > normal path resolution instead of a more expensive query to retrieve
> > an entry.
>
>  Cool.

One caveat though, the names you use must then be valid JCR names, not
just any strings. As a workaround you can use some encoding if you
need to reliably use externally generated names as JCR names.

Also, note that Jackrabbit currently starts hitting performance issues
if you store too many (>> 1k) child nodes under a single parent. A
typical workaround to this issue is to split the child nodes into a
subtree based on the first few characters of the child node name.

> Another question though - which node type do I use to disallow same name
> siblings? I'm not quite keen on doing the File/Folder thing for some reason
> (maybe I should be?). I don't see any other node types that disallow same
> name siblings though. Does that mean I need to create my own node type?

I would probably use an nt:folder for the container node and a new
"atom:entry" subtype of nt:hierarchyNode for the entry nodes (or even
nt:file with custom jcr:content resource nodes). The more you leverage
the existing node types, the easier it will be to integrate with other
JCR tools (for example a file system mapping will definitely know what
to do with an nt:folder node).

Alternatively, for maximum flexibility, you can create your node types
from scratch. Either approach is valid.

> And if I create my own node type does that mean I have to do so via the
> Jackrabbit APIs? I don't see a way to do so via the JCR API.

JCR 1.0 didn't standardize node type management (it'll be standardized
in JCR 2.0), so currently you need to use a Jackrabbit-specific
extension to register new types. See the JackrabbitNodeTypeManager
extension interface in the jackrabbit-api package.

BR,

Jukka Zitting