Hi Julian, Michael and Robert first of all thanks for the suggestions. I'm using Oak directly inside my application, so I guess the Sling Pipes are not something I can use, or not? Is the concept of Pipe already defined in some way inside oak?
Marco. On Fri, May 19, 2017 at 10:39 AM, Julian Sedding <[email protected]> wrote: > 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 <[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] > > > > 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. > >> >
