jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@adobe.com>
Subject Re: Migration without an embedded Jackrabbit
Date Mon, 14 Oct 2013 17:20:12 GMT

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.

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).
This specially might be useful, if the migration also includes some more complex reconfiguration,
e.g. setup a highly clustered environment or special datastores.

Regards, Toby

On Mon, Oct 14, 2013 at 6:46 AM, Jukka Zitting <jukka.zitting@gmail.com<mailto:jukka.zitting@gmail.com>>

On Mon, Oct 14, 2013 at 9:09 AM, Felix Meschberger <fmeschbe@adobe.com<mailto:fmeschbe@adobe.com>>
> 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
> than migrating from one version of JR2 to the next. I would even assume it is way more
> than migrating from JR1 to JR2.

Yes, that's definitely true.

As for the timing assumptions, based on rough estimates I'm expecting
that a fairly large (i.e. millions of nodes) repository could be
upgraded in minutes with custom upgrade code vs. hours with standard
Jackrabbit components. Definitely not as smooth or fast as past
Jackrabbit upgrades, but still reasonable and IMO worth the overhead.

> So, let's agree to disagree ;-)

Thanks for sharing your concerns! Unless others also weigh in on the
side of a separate upgrade tool, I think for now I'd still give a go
for the proposed custom/duplicate code. But I'll keep an eye on the
amount of extra complexity, and as Michael noted, fall back to the
separate tool if the amount of duplication/overhead seems to start
becoming unmanageable. The PMs in Jackrabbit are now at 15kLOC, so my
warning bells would start ringing at around 2kLOC of extra code for PM


Jukka Zitting

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message