Hi Nicolas, Very nice ideas. You made me think of a simple and beautiful solution based on your mentioning of plugins:
For example, you create a plugin called UpgradeToOfbiz16 and UpgradeToOfbiz17 etc ... and this plugin when installed using ./gradlew installPlugin -PpluginName=UpgradeToOfbiz16 would take care of everything :) so this would be things like: - changes to the database. maybe we can even use something like liquibase - copying / adding / deleting - installing or uninstalling other plugins So someone takes care of all the complexity and users just install another plugin :) I don't know if this is sort of what you have in mind? Taher Alkhateeb On Friday, 29 July 2016, Nicolas Malin <nicolas.ma...@nereide.fr> wrote: > Many times when I try to refactor some code, I discovered some entities > that need to be refactored in order to homogenise or improve them with > the new framework functionnalities. > > We have a page to describe how to do this migration for each modification > https://cwiki.apache.org/confluence/display/OFBIZ/Revisions+Requiring+Data+Migration+-+upgrade+ofbiz > > I think that this is not easy for an end user nor useful with the OFBiz > release workflow. > Maybe we can improve it with this : > * Organize this page by OFBiz release branch since we don't change the > data model on stable (all the release) branch. When we announce the > availability of a new release branch, we can fix the data model changes > between this branch and the previous one > * Create a state table to indicate some information between the OFBiz and > the database, I think about the OFBiz release that exploit this database > * Store each datamodel migration script into a specific directory for > each component. Those scripts describe the migration through SQL scripts, > dedicated services or any automated operations needed to achieve the > migration. (and maybe we should use plugins for that) > * Create a new build target to apply the upgraded datamodel > ** check the database OFBiz release > ** apply migration scripts for each component > ** increase the database OFBiz release > > If we have a more efficient datamodel modification workflow, we can > improve and homogenise our historical datamodel with serenity. > > WDYT ? > > > -- > [image: logoNrd] <http://nereide.fr/> > Nicolas Malin > The apache way <http://theapacheway.com/> : *Openness* Technical > decisions are made publicly > informat...@nereide.fr > <javascript:_e(%7B%7D,'cvml','informat...@nereide.fr');> > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54 > Apache OFBiz <http://ofbiz.apache.org/> | The Apache Way > <http://theapacheway.com/> | ofbiz-fr <http://www.ofbiz-fr.org/> | réseau > LE <http://www.libre-entreprise.org/> >
