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 09:00:11 GMT


On 10.5.12 9:43, Julian Reschke wrote:
> On 2012-05-10 10:29, Michael Dürig wrote:
>>>>> 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.
>
> So how do you express a reference to the parent node in a path property
> inside Oak Core?

My thinking was to make this opaque to oak-core. That is, set the value 
of the path property to the jcr path and let oak-jcr handle it. Unless 
there is a case (which might well be) where we need to dereference such 
paths properties from within oak-core this should work.

>
>>>>> 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/../..
>
> Yup. What I meant is that we may need a way to switch off normalizing.

Ah ok. That shouldn't be difficult.

>
>> 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.
>
> This might break assumptions on stability of path property values. If
> the client sets a relative path it probably expects it to stay relative,
> so that the path continues to work when the node is moved.

I was just talking of resolving it (under the above opaqueness 
assumption). I didn't mean to save that dereferenced and normalized path 
to the path property. That surely doesn't work.

Michael

>
>>>>> 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