Hi Marco It sounds like you are dealing with a JCR-based application and thus you should be using the JCR API (directly or indirectly, e.g. via Sling) to change your content.
CommitHook is an Oak internal API that does not enforce any JCR semantics. So if you were to go down that route, you would need to be very careful not to change the content structure in a way that essentially corrupts JCR semantics. Regards Julian On Tue, May 16, 2017 at 6:33 PM, Marco Piovesana <pioves...@esteco.com> 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 <reka...@adobe.com.invalid> > 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 >>  during the migration. They should be included in the class path with >> the ServiceLoader mechanism . >> >> Regards, >> Tomek >> >>  http://jackrabbit.apache.org/oak/docs/architecture/ >> nodestate.html#The_commit_hook_mechanism >>  https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html >> >> -- >> Tomek Rękawek | Adobe Research | www.adobe.com >> reka...@adobe.com >> >> > On 14 May 2017, at 12:20, Marco Piovesana <pioves...@esteco.com> 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. >>