[
https://issues.apache.org/jira/browse/OAK-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829859#comment-13829859
]
Michael Dürig commented on OAK-1179:
------------------------------------
FTR here is what it takes to convert from a JCR path to an Oak path:
* Resolve identifier path elements
* Resolve "relative" path elements (. and ..)
* Map name space prefixes
* Map fully qualified name spaces (mind OAK-74)
* Check local names for invalid characters
* Handle indexed names (i.e. same name siblings)
This is currently done preemptively by {{NamePathMapperImpl.getOakPath()}}. To
optimise the potential more expensive parts of this mapping this function
relies on some heuristics ({{NamePathMapperImpl.needsFullMapping()}}), which
allows it to fall back to a simpler form of parsing. This heuristics has been
in the centre of some controversy in the past since it kept (and keeps, e.g.
OAK-1174) favouring performance over correctness.
I suggest we follow a similar path for converting JCR paths as for paths: wrap
the conversion into a thin wrapper and perform all conversion and validation as
late as possible leveraging memoisation to avoid duplicate work.
> Use dedicated Path class for handling paths in Oak
> --------------------------------------------------
>
> Key: OAK-1179
> URL: https://issues.apache.org/jira/browse/OAK-1179
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
> Reporter: Michael Dürig
> Fix For: 0.14
>
> Attachments:
> 0001-OAK-1179-Use-dedicated-Path-class-for-handling-paths.patch
>
>
> As discussed (for example [here |
> http://markmail.org/message/abdmqgultkpfwb3x] several times before using
> naked strings for paths is troublesome. OAK-1168 and OAK-1174 are only the
> latest of a long history of issues we suffered because of this.
> While wrapping the path and related entities into dedicated classes will add
> some overhead at first. It will OTOH clearly communicate the intend of what
> otherwise are just naked strings. In addition it will introduce a clear
> boundary for optimisations while in the string case these blur with the
> client code.
> I thus propose to introduce a dedicated class for paths in Oak. Such a class
> could serve as a container for the string, which is the lazily acted upon as
> required.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
