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: Paths in Oak
Date Wed, 13 Nov 2013 16:13:56 GMT

On 13.11.13 4:31 , Jukka Zitting wrote:
> Hi,
> On Mon, Nov 4, 2013 at 6:28 AM, Michael Dürig <mduerig@apache.org> wrote:
>> Wrapping the path and related entities into dedicated classes will surely
>> add some overhead at first. But 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.
> Would it be possible for us to achieve the best of both worlds here?
> I'm thinking of potential Path and Name classes as just thin type-safe
> wrappers around the underlying Strings.

Yes, that was my thinking. Not sure if we even need the name classes.

> When reading content that's already cached (which is the common case),
> path handling becomes a major component in access performance (see my
> comment on OAK-1168 for some figures), so it's critical for it to stay
> as lightweight as possible. That's the main reason why I'd like to do
> as little parsing of the given path strings as possible and avoid any
> extra transformations.

Agree. And I even think this should be easier with dedicated classes.

> But you're right in that extra type-safety would make things clearer
> and help avoid errors (currently we just rely on naming patterns like
> oakPath vs. jcrPath). Also, such wrappers might make it easier to
> address OAK-1168/OAK-1174 without too much overhead.

I created https://issues.apache.org/jira/browse/OAK-1179 to track this.


> BR,
> Jukka Zitting

View raw message