jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Paths in Oak
Date Wed, 13 Nov 2013 15:31:21 GMT

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.

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.

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.


Jukka Zitting

View raw message