That would be a great addition. It may be hard to change the existing options as that could break downstream use cases but I'm sure there's ways of updating this. I took a look at the code and I'm not familiar enough with oak in this use case to make that change.
- Jason On Thu, Dec 6, 2018, at 2:43 PM, Eric Norman wrote: > Hi Jason, > > I would think the ContentLoader could be enhanced to provide more granular > import logic than the "overwrite" and "overwriteProperties" directives > provide. > > For a point of comparison, in a previous (non-sling) project I worked on we > had a similar mechanism for importing content into a taxonomy. The > solution we ended up with for this kind of problem was to have a mechanism > to specify an import sync mode that changed how the new information was > interpreted. > > For example, the import "sync mode" could be set to something like this > with a directive (or with a special tag within the content itself): > > - default - merge the new content into the existing taxonomy overwriting > anything existing at the same location > - update - merge the new content into the existing taxonomy by > overwriting/updating existing content but don't create anything that > doesn't already exist > - add - merge the new content into the existing taxonomy but don't add > or update any items that already exist > - sync - same as "default" but remove all nodes from each of the parent > nodes if there is no equivalent item in the new content. > > > Regards, > Eric > > On Thu, Dec 6, 2018 at 10:44 AM Jason E Bailey <j...@apache.org> wrote: > > > We've set up a process to import content into our Sling instance and > > we're running into a problem with the ContentLoader. > > The use case is that a set of data that is managed in another part of > > our company is being provided to us in the form of a JSON object for > > loading into our Sling environment. > > This works. However, this content changes daily, sometimes properties > > will change and sometimes node structure. > > We don't want to say "overwrite" because that causes the entire tree > > structure to be deleted which is really intensive, however if we > > don't say "overwrite" then nodes that are removed from the import > > continue to exist. > > Effectively what we need is a delta, we want to delete nodes if they > > aren't in the import but otherwise leave it alone, the same thing with > > properties. > > Which, unless I'm missing something, is not a function the > > importer supports. Has anyone had to deal with this? Maybe used a > > different process? > > Thanks > > - Jason > > > > > >
