jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: path parser changes, was: index handling
Date Mon, 21 May 2012 16:31:03 GMT


On 21.5.12 17:10, Julian Reschke wrote:
> On 2012-05-16 14:40, Julian Reschke wrote:
>> On 2012-05-15 23:26, Julian Reschke wrote:
>>> ...
>>
>> Summarizing from a chat I just did with Jukka:
>>
>> 1) one goal for the path mapping (JCR->OAK) is to have as many cases as
>> possible where we don't have to map:
>>
>> a) if a path does not contain one of "{}:[]", we don't need to map
>>
>> b) if the current session has no active namespace remappings and the
>> path does not contain one of "{}[]", we don't need to map. (Note that
>> this mean that we can leave /parent/child/jcr:content alone if no
>> namespaces have been remapped)
>>
>> 2) Have the path mapper (JCR->OAK) deal just with prefix rewriting and
>> expanded name resolution, and return either the original String (taking
>> the potential shortcuts into account) or the mapped String
>>
>> 3) For JCR methods that create new nodes (addNode, destination path in
>> copy / move), have a method that splits into parent path and child name.
>> The latter can be checked for the presence of [] then (in which case the
>> method can throw)
>>
>> 4) In general, do not normalize paths, just walk the internal node tree.
>>
>> 4a) Note that this assumes that we "walk" the tree (for some value of
>> "walk") without being stopped by access control.
>>
>> Feedback appreciated, Julian
>
> I just had a look at the current code, and it seems the right way to
> proceed is to remove the following parts from JcrPathParser:
>
> - identifier paths (we already do this elsewhere)
> - index handling (maybe except for syntax checks)
> - . and .. handling
>
> So this was leave us with:
>
> - syntax checks
> - expanded name resolution
> - prefix rewriting
>
> I just tried this and it breaks only the NamePathParserImplTests (that
> assume this code is there), and a few TCK cases that make assuptions of
> index handling (which we'll do somewhere else as well).

I'm fine with such a change. However we will need to take that relative 
path segments (. and ..) are never passed to the Oak API. That is,

   node.getNode("foo/../../bar")

should not pass this path verbatim to the Oak API.

Michael




Mime
View raw message