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: ItemInfo.getParentId()
Date Thu, 16 Nov 2006 08:20:35 GMT
Marcel Reutegger schrieb:
> Hi,
> 
>> Marcel Reutegger schrieb:
>>> major parts of the jcr2spi currently rely on hierarchical caching 
>>> structure of nodes and properties. which means if an item is in the 
>>> cache it's ancestors are cached as well. this simplified the handling 
>>> of spi ids a lot because in some cases they can be very volatile. 
>>> think of same name siblings and parent nodes that become referenceable.
> 
> another issue with a non-hierarchical caching structure is the way how a 
> save on an item is specified. if you have multiple disconnected item 
> sub-tree fragments (which contain modified items) it will be impossible 
> to find out whether one of the sub-trees is included in a save call. 
> even though I'd also be in favor of only reading what is really 
> necessary, this constraint seems to even demand that an implementation 
> resolves the ancestor hierarchy.

I understand the problem in general, but it certainly doesn't apply for 
the specific use case I have (having the contents of jcr:versionStorage 
not being enumerable).

It seems to me that -- independantly of SPI -- we need to discuss 
whether "this" is legal behavior for JCR implementations. If it is, we 
need to define how this works with saving changes in general, and the 
transient layer in JCR2SPI in particular. If it isn't, that should be 
spelled out as well, because it may affect other implementors as well.

In general, I think the assumption that if a user has read access to 
/a/b/c necessarily means (s)he also has access to /a and /a/b is flawed.

Best regards, Julian



Mime
View raw message