Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.20 as permitted sender)
Message-ID: <47B08E5F.9050207@gmx.de>
Date: Mon, 11 Feb 2008 19:05:19 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes
 that changes in one session are immediately visible in different session
References: <10340167.1202296988432.JavaMail.jira@brutus>
 <47A9A975.70701@gmx.de> <47A9D3EE.5000108@day.com> <47A9D69B.60806@gmx.de>
 <47AABD1C.5020500@gmx.net> <47AAE7B4.4070803@gmx.de>
 <47AAFD83.1090001@gmx.net> <47AB02BD.20500@gmx.de> <47AB1A68.5040404@gmx.net>
 <CA0E37595DA8C34CA4E7732B793D569B2D863B@CEXCS001.SYNCHRONICA.COM>
 <47AC4DEB.2060900@gmx.net> <47AC54B5.3070101@gmx.de>
 <47AC5A9E.8060305@gmx.net> <47AC5ED0.6080708@gmx.de>
 <47AC81A5.4050309@gmx.net>
In-Reply-To: <47AC81A5.4050309@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Marcel Reutegger wrote:
>>> Hmmm, does that mean a batch read should also be allowed to return 
>>> ChildInfo, with the restriction that it must be complete, when sent?
>>
>> That would be less expensive than returning ItemInfos for the 
>> children. But would it be useful?
> 
> Maybe the more interesting question is, how useful is it to have the 
> distinction between NodeInfo and ChildInfo?
> 
> ChildInfo is basically a stripped down NodeInfo. With little effort it 
> would even be possible to have NodeInfo extends ChildInfo. Not sure how 
> useful that is, but since we don't have that inheritance in code and at 
> the same time nearly a 100% overlap it makes me suspicious.

Yep.

> Here's another idea:
> 
> introduce a method ChildInfo[] NodeInfo.getChildInfos(). The method 
> either returns:
> 
> - all child infos, which also gives the correct number of child nodes. 
> this may also mean that an empty array is returned to indicate there are 
> no child nodes.
> - null, to indicate that there are *lots* of child nodes and the method 
> RepositoryService.getChildInfos() with the iterator should be used.

Having the method on NodeInfo would help keeping state; but my 
impression was that this design pattern was something we don't do. For 
instance, why wouldn't we also use it for retrieving properties (which 
has similar problems)?

I am also not sure why we just wouldn't want getChildInfos return 
something that can both provide members, the count, and be evaluated 
lazily when needed.

>>>> And how should the SPI implementation know that somebody *wants* to 
>>>> retrieve all children?
>>>
>>> I'm not sure I understand your question, because there is 
>>> RepositoryService.getChildInfos(). Do you mean something else?
>>
>> I was thinking in terms of PROPFIND Depth 0/1, where 1 includes 0. 
>> That is, it's possible to return information about the node and all 
>> it's children, saving yet another round trip. Which may not be 
>> sufficient justification.
>>
>> But returning ChildInfos will not be sufficient here, because there is 
>> no Batch aspect built in; thus, JCR2SPI still needs to fetch the 
>> ItemInfos for each child node in a separate call.
> 
> example content:
> 
> /a
>   /b
>   /c
> 
> Considering the above mentioned method an SPI implementation could return:
> NodeInfo(a, [ChildInfo(b), ChildInfo(c)]), NodeInfo(b, []), NodeInfo(c, [])
> 
> plus whatever properties are considered useful.
> 
> would that work?

Yes, in particular if we make NodeInfo extend ChildInfo, so no 
duplication is needed here.

BR, Julian