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
