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,


should not pass this path verbatim to the Oak API.


View raw message