Hi Marco On Fri, May 19, 2017 at 2:10 PM, Marco Piovesana <pioves...@esteco.com> wrote: > Hi Julian, Michael and Robert > first of all thanks for the suggestions. > I'm using Oak directly inside my application,
Do you mean you are not using the JCR API? > 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? No Oak has no such concept. Sling Pipes is an OSGi bundle that is unrelated to Oak but uses the JCR and Jackrabbit APIs (both are implemented by Oak). Regards Julian > > Marco. > > On Fri, May 19, 2017 at 10:39 AM, Julian Sedding <jsedd...@gmail.com> 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 <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 >> >> [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 >> >> 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. >> >> >>
