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: Migration without an embedded Jackrabbit
Date Wed, 16 Oct 2013 14:26:58 GMT

On Mon, Oct 14, 2013 at 1:20 PM, Tobias Bocanegra <tripod@adobe.com> wrote:
> I second Felix' comments and prefer a standalone upgrade tool. this does not mean that
an upgrade
> is always a manual step. the embedding application (e.g. Sling) can still contain the
tool and
> auto-upgrade if desired.

After some more work on this, I'm actually inclined to go with a
hybrid solution somewhat along those lines.

I'd implement a custom code for simple upgrades (default Jackrabbit
configuration, etc.) that can reasonably be done transparently without
extra user action or with any of the extra Jackrabbit dependencies,
but fall back to a separate upgrade tool with standard Jackrabbit
components for more complex cases and situations where the user in any
case wants full control over the upgrade. This should be reasonably
straightforward to implement without much code duplication. For now
I've added a simple "ugprade" mode to oak-run as an initial take on
such a separate upgrade tool.

I even think I have a solution that allows me to avoid having to embed
all the Jackrabbit dependencies in an OSGi environment. Basically I'd
define a few simplified extension interfaces in oak-upgrade for things
like Jackrabbit persistence managers and other required internals, and
Jackrabbit bundles installed in the same OSGi container can offer the
required implementations for those interfaces.

> I even think that a migration could be done purely on the JCR level, for example using
vlt rcp
> (which does not support copying versions, but this could be improved).

Right. Something like that would ultimately be quite nice, as it would
give us an implementation-independent way to backup and restore entire
repositories, a bit like the dump features in many SQL databases work.
Though getting to that point will probably require quite a bit of work
(including API extensions required for version support, etc.), and it
will probably never reach similar performance as a direct lower-level
upgrade can.


Jukka Zitting

View raw message