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 Mon, 14 Oct 2013 13:02:29 GMT
Hi,

On Mon, Oct 14, 2013 at 4:38 AM, Felix Meschberger <fmeschbe@adobe.com> wrote:
> IMNSHO migration of Jackrabbit 2 based repositories to Oak is a one-shot problem:
> you apply this once to a repository and be done. So why load the application with
> a host of unneeded pieces ?

I'd like to make the upgrade as smooth and transparent as possible. I
all Jackrabbit versions so far the upgrade has required just starting
up a new version of the repository, and any required migration steps
have been handled transparently under the hood.

> Rather, I suggest to come up with a standalone application, which can be a conglomerate
> of original Jackrabbit and Oak libraries and which do the migration in one step.

That's a valid alternative, especially since the Oak upgrade is by far
the most complex migration so far. And I agree with your concerns
about code duplication. In this case though I believe the benefits
outweigh the drawbacks, see below.

> This application can be optimized and fine-tuned to just this single use-case: migration.

Unfortunately it can't. While the Oak internals are designed with
these kinds of bulk operations in mind, the Jackrabbit internals are
not. There are some pretty major optimizations (like streaming bundles
from a persistence manager, vs. loading them one-by-one) that we could
do with custom upgrade-oriented code and that wouldn't be available
with the standard Jackrabbit components.

> This way, both Jackrabbit 2 and Oak applications stay clean of such migration junk.

Note that with the approach I'm proposing, all the custom migration
code would go to the oak-upgrade component that's independent of the
rest of the stack. Once the upgrade is done, a deployment can safely
drop that component.

> This also makes it clear that migration of storage from Jackrabbit2 to Oak is not
> something that can and will be done by just snipping your fingers, but which is
> a potentially long-running and complex operation.

My goal here is to make the upgrade *not* be a long-running and
complex operation.

BR,

Jukka Zitting

Mime
View raw message