Marco, Judging from your original question: is there a problem with the JCR-based approach for migrating the content? If so, can you paste the code and explain what the problem is?
Cheers Michael On 19/05/17 09:04, "Julian Sedding" <[email protected]> wrote: >Hi Marco > >In this case I think you should use the JCR API to implement your >content changes. > >I am not aware of a pure JCR toolkit that helps with this, so you may >just need to write something yourself. > >Regards >Julian > > > >On Fri, May 19, 2017 at 5:00 PM, Marco Piovesana <[email protected]> wrote: >> Hi Julian, >> I meant I'm using Oak not Sing. Yes I'm using JCR API. >> >> Marco. >> >> On Fri, May 19, 2017 at 2:22 PM, Julian Sedding <[email protected]> wrote: >> >>> Hi Marco >>> >>> On Fri, May 19, 2017 at 2:10 PM, Marco Piovesana <[email protected]> >>> 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 <[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. >>> >> >> >>> >> >>> >> >> >> >> -- >> >> marco piovesanA >> Enterprise Application >> >> >> >> *ESTECO* | EXPLORE DESIGN PERFECTION >> >> AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY >> Phone: +39 040 3755548 - Fax: +39 040 3755549 >> [Website] <http://www.esteco.com> | [Twitter] >> <https://twitter.com/esteco_mF> | [Facebook] >> <https://www.facebook.com/esteco.spa> | [Linkedin] >> <https://www.linkedin.com/company/748217> >> Pursuant to Legislative Decree No. 196/2003, you are hereby informed that >> this message contains confidential information intended only for the use of >> the addressee. If you are not the addressee, and have received this message >> by mistake, please delete it and immediately notify us. You may not copy or >> disseminate this message to anyone. Thank you. Please consider the >> environment before printing this email.
