jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: index handling
Date Tue, 15 May 2012 19:32:35 GMT
On 2012-05-15 20:39, Jukka Zitting wrote:
> Hi,
> On Tue, May 15, 2012 at 7:58 PM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> This isn't sufficient; there are API signatures where even a "[1]" on the
>> final path segment is forbidden, such as when creating new nodes.
>> We can either hack these restrictions into NodeImpl, SessionImpl and
>> friends, or extend the path mapper to optionally check.
> Couldn't we just pass them as is down to oak-core, where such names
> can be rejected as invalid by a commit hook? Or if an exception is
> required before save(), I'd rather have such checks explicitly in
> NodeImpl&  friends instead of overloading the path mapper with extra
> responsibilities.

So you want it either higher in the stack or lower but not here? :-)

"higher" is tricky, because to do it properly, you need to parse the 
path. I thought we don't want to do that more than once.

"lower" might actually work.

> IMO it should be possible for the path mapper to be a no-op whenever
> no session-local namespace re-mappings are in place. In such cases as
> long as a path doesn't contain any {expanded}names, the mapper
> shouldn't need to do any other parsing and can return the exact same
> path string instance it received.

True; we just need to add index processing to that list.

> A separate path resolver (see my other post about the mapper/resolver
> distinction) should take care of evaluating the mapped path string in
> a specific context. Such resolution would for example involve finding
> the parent node of the relative path provided to an addNode() call.
> In cases like addNode(), neither the path mapper nor the resolver
> should have to worry about rules like whether an index is allowed in
> the last path element. Instead the relevant code should look something
> like this:
>      // Map and validate the last name segment of the given path
>      String jcrName = PathUtils.getName(relPath);
>      String oakName = nameMapper.getOakName(jcrName);
>      if (oakName == null || isInvalidNodeName(oakName)) {
>          throw new RepositoryException("Invalid node name: " + relPath);
>      }
>      // Map and resolve the relative path leading to the new node
>      String jcrPath = PathUtils.getParentPath(relPath);
>      String oakPath = ssessionDelegate.getOakPathOrThrowNotFound(jcrPath);
>      NodeDelegate parent = dlg.getChild(oakPath);
>      if (parent == null) {
>          throw new PathNotFoundException(relPath);
>      }

Yes, we can make this work, but it essentially means that the path is 
parsed twice.

Best regards, Julian

View raw message