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> >
