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 Thu, 07 Feb 2008 16:25:28 GMT
 
My main problem with SPI is that if I return depth=1 results from getItemInfos (a NodeInfo
for each subfolder), JCR2SPI ends up subsequently calling getChildInfos anyway, to find out
what ALL the children are, regardless of the fact that I just returned what all the children
are in my GetItemInfos response.

>From JCR2SPI's point of view, the problem seems to be that it had no way of knowing whether
I returned SOME, or ALL, of the subfolders. In that sense, it's the Iterator return value
types that I have a problem with. I would prefer returning a container, that could encapsulate
the Iterator, but also allow for declaring formalized hints, and maybe even out-of-band data
that JCR2SPI chooses to look at as hints.

And the hint JCR2SPI needs from getItemInfos is "response includes all children" (or "this
response contains depth=1 results").

It would also not hurt for depth=0 results to be able to return the equivalent of IMAP's \HasChildren
flag. Because in that case, getItemInfos could return depth=0 results, and then in the case
where there are no children, JCR2SPI could avoid the unnecessary getChildInfos when there
are no results.

David
-----Original Message-----
From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
Sent: Thu 2/7/2008 3:49 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:
> I think I understand batch read, and how JCR2SPI would use that. What I 
> don't see how it helps in this case.
> 
> An SPI implementation *could* return ItemInfos for all children when the 
> NodeInfo for a collection is fetched, but how would it know that anybody 
> wants to see the members?

Angela and I discussed this some time ago and we decided that for now we leave 
to up to the implementation. basically for simplicity. See also javadoc 
RepositoryService.getItemInfos().

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

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