Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAOnkMupRHpgMB0TVWEmk7sj7S97g2hmi3F9WYFz8ZfSVG2_nA@mail.gmail.com>
References: <4F60A2FB.8010203@gmx.de>
	<CAAOnkMupRHpgMB0TVWEmk7sj7S97g2hmi3F9WYFz8ZfSVG2_nA@mail.gmail.com>
Date: Thu, 15 Mar 2012 11:05:57 +0100
Message-ID: 
 <CAFYk8NmwF=VwTKufv0D4KZgEHL1Maw5TizbCzUjPs-sCuAJbQQ@mail.gmail.com>
Subject: Re: Semantics of MicroKernel.getNodes()
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 15, 2012 at 9:57 AM, Bart van der Schans
<b.vanderschans@onehippo.com> wrote:
> Hi,
>
> On Wed, Mar 14, 2012 at 2:54 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> Hi there,
>>
>> I'm looking at MicroKernel.getNodes(), and I believe the semantics might
>> perform non-optimal unless we get the property filtering right.
>>
>> A typical use case always is browsing a repository using a tree view.
>>
>> A tree view usually needs, given a node N:
>>
>> - all or a subset of all properties of node N
>>
>> - the set of child node names, and for each of these child nodes, a
>> predefined set of properties that will allow the caller to decorate the node
>> properly -- such as whether it's a container, and maybe the type).
>
> Not sure if it matters at all for this specific thread, but another
> very common use case with trees:
> - a check if node N has children or not

there's the system generated :childNodeCount property
and there's also the getChildNodeCount(String path, String revId) method.

cheers
stefan

>
> That check should/could be a lot more lightweight than fetching a list
> of child node names.
>
> Regards,
> Bart