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
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
(sorry for the late reply - had a customer visit for most of the
previous week).
Marcel Reutegger schrieb:
the current design of the spi demands that the client on top of the spi
resolves paths to ids and vice versa. this design was actually just
borrowed from the jackrabbit implementation,
Hi Julian,
Julian Reschke wrote:
here's a question on ItemInfo.getParentId().
In my store, all version histories live directly below
/jcr:system/jcr:versionStorage. However, getNodeIds() will not return
any children. As far as I understand, that is legal in JCR (versioning
nodes are exposed
Marcel Reutegger schrieb:
Hi Julian,
Julian Reschke wrote:
How about using an intermediate structure like jackrabbit does and
expose the version histories that way?
I have to confess that I'm not sure how it currently does that
(pointer?).
jackrabbit uses the 6 highest digits of the uuid
Marcel Reutegger schrieb:
...
hmm, the more I think about it, we might have to deal with this issue at
other occasions. It may happen that a node is returned by a query that
has never been requested, but its parent node has. assuming that the
jcr2spi layer still has the old version of the
