jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session
Date Mon, 11 Feb 2008 18:05:19 GMT
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.


> 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

View raw message