@scraps, note that I haven't tested your framework, it's in my todo list, so maybe it already solves more or less all cases. I think the advantage of having the migration process with an external tool instead of inside the modules themselves is that it's more flexible when there are exceptions or the default behaviour does not fit one's needs.
sraps wrote: > @albertca > > I do not think, that the approach of embedding the migration logic inside > module would work, because fields are dependent on each other (think of > onchange event), and those may change as well. So it is possible to create > the script or scenario manually. > I already mentioned the problem of dependencies in my post. sraps wrote: > > The other thing to consider: in many cases enterprise want to add some > modules in addition to those which was in the legacy setup. Think of module > X, which adds mandatory field ABC (which has no default values) to a model > created by other module. What if that module X was not present in legacy > setup, but needs to be used on a new one? > What's the problem with with doing the migration using the same modules and then adding the new ones? Even more, how could that module X work with an existing database of the same version if it adds a mandatory field and does not have a default value? You will have the same issue installing the module whether data is comming from an older version or is from the current one. Kaspars ------------------------- http://kndati.lv[/quote] ------------------------ Albert Cervera i Areny http://www.NaN-tic.com OpenERP Partners http://twitter.com/albertnan -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=61334#61334 -------------------- m2f -------------------- _______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman2/listinfo/tinyerp-users
