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: value conversions, and relative paths in Oak
Date Thu, 10 May 2012 08:29:36 GMT
>>> 2) we didn't round-trip a relative path of ".". Now we do, but I'm not
>>> sure I got the mapping correct. What is a same-node reference in Oak
>>> path syntax? "." or empty string?
>>
>> well, i would expect "."
>
> Indeed.

Currently there is no notion for .. and . in Oak paths and I would leave 
it at that. I.e. oak-jcr needs to take care to normalize paths before it 
passes them to the Oak API. But of course we should use the 
JcrPathParser to do that.

>
>>> I also fear that we need to be able to
>>> round-trip relative paths like "../foo/bar" in path values, which we
>>> currently do not. Do we need a "normalize" flag???
>>
>> i would expect that we need it sooner or later.
>
> +1

The JcrPathParser does already normalise. What it can't do is 
normalising "negative" paths like ../foo or foo/../..

See my other mail how that could be handled with the current setup. 
Alternatively we could also have the JcrPathParser accept a prefix path 
against which normalisation is done.

>
>>> 3) Node.getNode(".") failed because it looked for a child called ".". If
>>> have added a hack to make this work, but I'm wondering how to do this
>>> properly.
>>
>> imo oak paths should always be normalized except for path values.
>
> Which means that we need to expose that in the path mapping API, right?

In the sense I described above yes.

Michael

Mime
View raw message