(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, where the lower layers
don't know about paths but the items just have forward and backward
references (parent uuid, child node entries and property names).
I'm not so sure if we should move this task to the server. I think in
most cases a workspace is accessed in a traversal way. At least that's
what most methods in the JCR are about. To get a node or a property you
usually start from a node you accessed before.
But you are right that this design will cause problems when there are
ancestor nodes that cannot be accessed.
It will also cause problems when collections are really, really big.
in the meantime I realized that the IdFactory can do that for me,
assuming it allows
.createNodeId((NodeId)null, path);
...where path would be absolute -- which the one in spi2dav doesn't
(why?). (As a matter of fact a createNodeId(Path) signature would be
useful).
the method createNodeId(NodeId, Path) is meant for ids that are relative
to an existing id. createNodeId(String, Path) is what you are looking
for. here, the String uuid parameter is optional.
OK, thanks, works for me.
So given the fact that the SPI API at least in theory has the
capability to do the lookup without having to access the parent
collections, shouldn't JCR2SPI use that when circumstances require that?
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.
Well, the current design doesn't work for my current back end; and even
if I *could* change the back end, looking up nodes that have many
children will still be very expensive.
Does it make sense that I start trying to change JCR2SPI with respect to
this?
Best regards, Julian
