Not sure if you are talking about the patching system, but if yes you would provide a patch file that removes all the contents of file.
If we are just using versions it is indeed a bit more tricky. We would also need to have a way to list the definitions to remove. Regards, Serge... On Tue, Sep 18, 2018 at 11:23 AM Romain Gauthier <rgauth...@jahia.com> wrote: > > Hi Serge, > > In that context, how would we manage objects deletion from a plugin? > > Thanks! > > Romain > > On Tue, Sep 18, 2018 at 10:45 AM Serge Huber <shu...@apache.org> wrote: > > > Sorry, I didn't get around to this discussion but I think that > > versions would probably be cleaner. I was even looking at solutions > > such as JSON patch (https://github.com/java-json-tools/json-patch) to > > be able to perform modifications on parts of definitions instead of > > having to deploy a whole definition again. > > > > We had discussions about adding lots of metadata, including last > > modification dates, maybe even hashes for the definition files, to > > know if a definition has been changed or not. > > > > I think that one of the advantages of the patch idea is that you could > > try to patch something if it's compatible, and if it's not you would > > not deploy it. But this idea would mostly be for use cases where you > > are interested in modifying something that comes out of the box in > > Unomi, not for upgrading a plugin. > > > > With versions at least we could also track if a definition is on the > > "default" version or has been modified somehow. > > > > For the cfg idea it feels weird to use a config file that way, maybe > > we should put the marker file elsewhere but to be honest I don't have > > a better idea :) > > > > Would love some input from JB or other Karaf experts :) > > > > Regards, > > Serge... > > > > On Tue, Sep 18, 2018 at 9:51 AM Thomas Draier <tdra...@jahia.com> wrote: > > > > > > Hi, > > > > > > I have to check, but the idea would be to be able to package this cfg > > file > > > beside the bundle. I'm not familiar with unomi:migrate command, but we > > can > > > imagine that this command would extract and deploy the cfg file from the > > > bundle - which would make the packaging easier (cfg directly inside the > > > plugin). The thing is that we need to be able to remove the file once the > > > definition has been "overridden" so that it's only done once, so the cfg > > > file should not be deployed automatically on each startup. > > > > > > Another idea I had was to store sort of "version" of the definition > > inside > > > the metadata, and check if the json file has a greater "version" defined. > > > That makes things even more easier when developing plugin and looks a > > > little more clean, but I don't know if it would cover correctly all use > > > cases. > > > > > > We should also extends the DeployDefinition shell command to be able to > > > redeploy all definitions of a bundle. > > > > > > Thomas > > > > > > > > > On Tue, Sep 18, 2018 at 1:33 AM Romain Gauthier <rgauth...@jahia.com> > > wrote: > > > > > > > Hello Thomas, > > > > > > > > Nice proposition.How would it work for developers that are building > > > > plugins? Would we have to add our own cfg file or somehow update the > > cfg > > > > file that you want to add? > > > > > > > > Since there is already a "unomi:migrate" command would you reuse that > > > > trigger to update / delete the definitions of the objects? > > > > > > > > Same question regarding the plugins, should we also implement "migrate" > > > > command? > > > > > > > > Thanks, > > > > > > > > Romain > > > > > > > > On Thu, Sep 13, 2018 at 6:22 PM Thomas Draier <tdra...@jahia.com> > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I'm having some issues with the deployment and redeployment of the > > json > > > > > files containing default definitions (segments, properties, etc..). > > Many > > > > > services have these loadPredefined* methods which load data into ES, > > > > based > > > > > on json definition files. These methods only load the content once, > > if > > > > the > > > > > object does not exist yet in ES. So if a bundle comes with an update > > of > > > > one > > > > > of these file, it will just be ignored. > > > > > > > > > > Actually there was one ticket about this : > > > > > https://issues.apache.org/jira/browse/UNOMI-182 , where definitions > > are > > > > > always redeployed when a bundle is in "snapshot" version - but never > > for > > > > a > > > > > release version. So that's nice when you are in development, but not > > > > > possible when upgrading a production environment. > > > > > > > > > > There also a console command to manually deploy a definition - which > > is > > > > > also nice but cannot be automated in a migration. > > > > > > > > > > Of course there's a reason - these objects can be modified > > afterwards by > > > > > using the API, and so restarting should not overwrite the > > modifications > > > > by > > > > > reimporting the file. Even if a module is updated and object is > > modified, > > > > > the user may not want to overwrite his changes. > > > > > > > > > > However in some cases the developer may want to force the update of > > some > > > > > specific objects ( it actually happened to us ). I'm looking for some > > > > > additional solution to force redeployment of a definition. > > > > > > > > > > So far i was thinking of adding a cfg file, which would list the > > > > properties > > > > > to redeploy. This file would be removed once the properties are > > updated, > > > > so > > > > > that they are reloaded only once and not on every startup. > > > > > > > > > > As a bonus, I would also need to be able to remove definitions the > > same > > > > > way. There's no way to do that now except using the REST API , it > > could > > > > be > > > > > good to also have a console command and to be able to remove > > definitions > > > > > with the same cfg file. > > > > > > > > > > What do you think .. ? > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > -- > > > > Romain Gauthier > > > > Product Manager at Jahia > > > > + 33 6 20 18 35 25 <+33%206%2020%2018%2035%2025> > > > > 8 Rue du sentier | 75002 Paris | France > > > > <https://www.jahia.com/about-us/news-events/events-webinars/jahiadays> > > > > > > > > > -- > Romain Gauthier > Product Manager at Jahia > + 33 6 20 18 35 25 > 8 Rue du sentier | 75002 Paris | France > <https://www.jahia.com/about-us/news-events/events-webinars/jahiadays>
