jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Migration without an embedded Jackrabbit
Date Mon, 14 Oct 2013 13:09:22 GMT

Thanks for the clarifications. Yet, they more confirm my first impression than they resolve
the concerns. 

Particularly your timing and smoothness assumptions. Migrating JR2 to Oak is much more complex
than migrating from one version of JR2 to the next. I would even assume it is way more complex
than migrating from JR1 to JR2.

So, let's agree to disagree ;-)


Am 14.10.2013 um 15:02 schrieb Jukka Zitting:

> 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

View raw message