On Wed, 2017-05-17 at 09:37 +0000, Michael Marth wrote: > Hi Marco, > > Maybe I don’t understand correctly your use case, but would it be > easier to simply write a script using the JCR API to do the changes > in the repo? > > Michael
For bulk operations like that Sling Pipes is also an options ( if you're using Sling ) https://sling.apache.org/documentation/bundles/sling-pipes.html https://adapt.to/2016/en/schedule/introduction-to-sling-pipes.html Robert > > > > > On 16/05/17 18:33, "Marco Piovesana" <[email protected]> wrote: > > > Hi Tomek, > > yes I'm trying to upgrade within the same repository type but I can > > decide > > weather to migrate the repository or not based on what makes the > > upgrade > > easier. > > The CommitHooks can only be used inside an upgrade to a new > > repository? > > What is the suggested way to apply backward-incompatible changes if > > i don't > > want to migrate the data from one repository to another but I want > > to apply > > the modifications to the original one? > > > > Marco. > > > > On Tue, May 16, 2017 at 4:04 PM, Tomek Rekawek <[email protected] > > nvalid> > > wrote: > > > > > Hi Marco, > > > > > > the main purpose of the oak-upgrade is to migrate a Jackrabbit 2 > > > / CRX2 > > > repository into Oak or to migrate one Oak node store (eg. > > > segment) to > > > another (like Mongo). On the other hand, it’s not a good choice > > > to use it > > > for the application upgrades within the same repository type. You > > > didn’t > > > mention if your upgrade involves the repository migration (in > > > this case > > > choosing oak-upgrade would be justified) or not. > > > > > > If you still want to use oak-upgrade, it allows to use custom > > > CommitHooks > > > [1] during the migration. They should be included in the class > > > path with > > > the ServiceLoader mechanism [2]. > > > > > > Regards, > > > Tomek > > > > > > [1] http://jackrabbit.apache.org/oak/docs/architecture/ > > > nodestate.html#The_commit_hook_mechanism > > > [2] https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html > > > > > > -- > > > Tomek Rękawek | Adobe Research | www.adobe.com > > > [email protected] > > > > > > > On 14 May 2017, at 12:20, Marco Piovesana <[email protected] > > > > > wrote: > > > > > > > > Hi all, > > > > I'm trying to deal with backward-incompatible changes on my > > > > repository > > > > structure. I was looking at the oak-upgrade module but, as far > > > > as I could > > > > understand, I can't really make modifications that require some > > > > logic > > > > > > (e.g. > > > > remove a property and add a new mandatory property with a value > > > > based on > > > > the removed one). > > > > I saw that one of the options might be the "namespace > > > > migration": > > > > - remap the current namespace to a different prefix; > > > > - create a new namespace with original prefix; > > > > - port all nodes from old namespace to new namespace applying > > > > the > > > > > > required > > > > modifications. > > > > > > > > I couldn't find much documentation on the topic, so my question > > > > is: is > > > > > > this > > > > the right way to do it? There are other suggested approaches to > > > > the > > > > problem? There's already a tool that can be used to define how > > > > to map a > > > > source CND definition into a destination CND definition and > > > > then apply > > > > > > the > > > > modifications to a repository? > > > > > > > > Marco.
