[
https://issues.apache.org/jira/browse/OAK-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13829998#comment-13829998
]
Jukka Zitting commented on OAK-1179:
------------------------------------
Agreed about the mapping part. I didn't yet want to touch that area, but I
would see it as natural for {{PathMapper}} to use {{Path}} instances for Oak
paths and strings for JCR paths.
As for the path conversion, I'd have the {{PathMapper}} take care of the
following responsibilities:
* Resolve identifier path elements
* Map name space prefixes
* Map fully qualified name spaces (mind OAK-74)
These are all easy to shortcut in the common case (no identifiers, no local
namespace mappings, qualified names only as JCR API constants). The shortcut
operation requires only a fast scan over the characters of the string. This
mapping step would only need to make sure that any syntactically valid JCR path
is correctly mapped. An invalid path can be passed on for lazy evaluation as
long as it matches the basic syntax requirements of {{Path}}.
The following tasks should be taken care of during path resolution, i.e.
mapping from the path to the corresponding {{Tree}} instance:
* Resolve "relative" path elements (. and ..)
* Handle indexed names (i.e. same name siblings)
Note that any invalid paths from the mapping step are guaranteed not to match
any content in the repository. An conversely, a path that matches content in
the repository, is guaranteed to be valid, so no further path parsing or
validity checks are needed.
Thus the last steps are only really needed when the path resolution fails to
match the path to an existing {{Tree}} instance:
* Check local names for invalid characters
* Check path for valid syntax (extra step as the shortcut above might have
missed some invalid constructs)
Since the last step is only needed for cases where matching content is not
found, it might conveniently be handled with a statement like {{throw
path.notFound()}}, where the {{Path.notFound()}} method would do the lazy path
validation and return the appropriate exception depending on whether the path
is valid or not.
> 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)
