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: value conversions, and relative paths in Oak
Date Thu, 10 May 2012 12:14:07 GMT
On 2012-05-10 11:00, Michael Dürig wrote:
> 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
>>>>>> 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 don't think that's going to work as then the persisted path depends on 
session namespace mappings.

>>>>>> I also fear that we need to be able to
>>>>>> round-trip relative paths like "../foo/bar" in path values, which
>>>>>> 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.

OK, trying to summarize:

- we allow relative paths inside path values; but we need to oakify them 
with respect to prefixes

- open question: we allow relative paths such as ".." but does that 
imply we do not normalize at all?

- relative paths in other methods (such as getNode()) are resolved to an 
absolute Oak path in oak-jcr

I think this means we need a variant of getOakPath() that doesn't make 
the path absolute. Any preferences about whether this should be a flag 
or a new method?

Best regards, Julian

View raw message