Many timeswhen I tryto refactor some code, I discoveredsome entitiesthat
need to be refactoredin order to homogenise or improve themwith the new
framework functionnalities.
We have a page to describe how to do thismigration 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 noruseful with the OFBiz
release workflow.
Maybe we can improve it withthis :
* Organizethis page by OFBiz releasebranchsincewe don't change the data
model on stable(all the release)branch.When we announce the availability
ofa new release branch, we can fix the data model changesbetween this
branch and the previous one
* Create a state table to indicate some information between the OFBizand
the database, I think about the OFBiz release that exploit this database
* Store each datamodel migrationscript intoaspecific directory for each
component. Those scriptsdescribe the migration throughSQLscripts,
dedicatedservicesor anyautomatedoperationsneeded to achieve the
migration.(and maybe we should use plugins for that)
* Create a new build target to apply the upgradeddatamodel
** check the database OFBiz release
** apply migration scriptsfor each component
** increase the database OFBiz release
If we have a more efficient datamodel modificationworkflow, we can
improve and homogenise our historical datamodel with serenity.
WDYT?
--
logoNrd <http://nereide.fr/>
Nicolas Malin
The apache way <http://theapacheway.com/> : *Openness* Technical
decisions are made publicly
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/>
