jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Rauschenbach" <David.Rauschenb...@SYNCHRONICA.COM>
Subject RE: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session
Date Fri, 08 Feb 2008 16:31:32 GMT
 
Distraction:

WebDAV notation is better for examples (nodes/collections end with slashes, items don't):

a/
  b/
  c/
  p1
  p2
d/

Back to the discussion: also worth mentioning is why a requested-depth argument is missing
from getItemInfos. It's just a little strange for the server to choose what to do, or to have
a pre-configured nodetype-specific batch strategy configured there, when the client is where
it's at, where it's known what's to be requested. Particularly if your front end is a WebDAV
query, which you're going to run through SPI to some WebDAV or other back-end. No matter what
the back-end is, you want to know the kinds of things you'd know if you were a WebDAV servlet,
including not only ItemId, but also depth, and named property lists, or allprops.

David
-----Original Message-----
From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
Sent: Fri 2/8/2008 5:21 PM
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
 
Julian Reschke wrote:
> Marcel Reutegger wrote:
>> I think your question reveals a design flaw in the batch read method 
>> RepositoryService.getItemInfos(). And it's not just about knowing all 
>> children, it's also about the order of nodes. Even if we are sure we 
>> got all children we still have to call getChildInfos() in case the 
>> parent supports orderable child nodes. Angela, please correct me, if 
>> I'm way off here...
> 
> Couldn't we just require that for orderable child nodes, their ItemInfos 
> are returned in order?

we could, but the issue whether child node infos are complete remains...

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

>>> 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?

regards
  marcel


 
Visit Synchronica at GSMA Mobile World Congress, Barcelona, 11-14 Feb, Hall 2, Booth #2J25
 
 

Mime
  • Unnamed multipart/mixed (inline, 7-Bit, 0 bytes)
View raw message