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