Hi Jukka, I want to start working on OAK-1222 (migrating group memberships). Is there already code and/or test cases that show how migration would work? are there already extension points for migrators?
regards, toby On Wed, Oct 16, 2013 at 7:26 AM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Hi, > > On Mon, Oct 14, 2013 at 1:20 PM, Tobias Bocanegra <tri...@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. > > BR, > > Jukka Zitting
