I would kindly disagree here on disqualifying pipes for *lot* of changes in the structures. I'd say that it's specifically better in those cases (It was first created for those), as you don't need the hassle of download / reupload and you don't have to mess around serialization issues.
Le mer. 10 juin 2020 à 14:57, Daniel Klco <dk...@apache.org> a écrit : > I agree with Nicolas' approach, however it depends on the scale you're > attempting to make changes. > > If it's fairly straight forward such as resourceType/a => resourceType/b or > property mapping, Sling Pipes is a great solution. If you need to do a > *lot* of > changes to the structure if your content, you may be better to pull it > down, transform it offline and reload. > > On Wed, Jun 10, 2020 at 2:51 AM Nicolas Peltier <npelt...@apache.org> > wrote: > > > Hi Carlos, > > > > one approach (not saying it's the best, i'm the main maintainer of them) > is > > to use a handful of sling pipes [0] and script to kick them off, or as > > package hooks. > > > > Nicolas > > > > [0] https://sling.apache.org/documentation/bundles/sling-pipes.html > > > > Le mar. 9 juin 2020 à 23:55, Carlos Munoz <camu...@redhat.com> a écrit : > > > > > Hi Sling devs, I was wondering what the best approach would be to take > an > > > exisiting repository and making changes to the content structure in a > > safe > > > and repeatable way. > > > > > > Thanks in advance! > > > > > >
