1. Mailing Lists
  2. Contributors
  3. Re: Removal of migration scripts on each new version

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Removal of migration scripts on each new version

Re: Removal of migration scripts on each new version

Avatar

Re: Removal of migration scripts on each new version

by
MoaHub, Graeme Gellatly
- 07/05/2025 00:29:27
There are some differences between enterprise and openupgrade migrations which mean that OCA migration scripts need checking anyway. For most migrations we fork/combine/edit scripts. There aren't that many anyway.

Take for example the removal of account.invoice to account.move and the impact on foreign key references. Within Openupgrade that is the responsibility of the module declaring the FK reference, within enterprise it is the responsibility of the module declaring the object. As a result, most openupgrade scripts weren't even required for that change.  Additionally, enterprise disables and changes very many things that don't need changing, OpenUpgrade does not. A recent one we had setting new stock locations for Intercompany, changing stock valuation methods, roughly 100 incorrect disabled views.

I also don't buy that the Odoo licence restricts migrating enterprise modules via OpenUpgrade. Given it is just scripts in an entirely separate repo, and the license expressly permits open source licensed extensions.



On Wed, May 7, 2025 at 9:27 AM Tom Blauwendraat <notifications@odoo-community.org> wrote:


On 5/6/25 20:37, Pedro M. Baeza wrote:
[Stefan wrote] >  True. Maybe a saner option would be to just always keep them, for say three versions (matching Odoo version lifecycle, c.q. maximum upgrade cycle).

With this, OCA issue trackers will be full of issues saying that the module X breaks their Odoo.sh build/test/migration, due to the already explained reasons to fail.

So I think Pedro and Stefan both have a point:

- Stefan is correct in saying that in some cases, maybe even in most cases, having the migration script there will do the right thing for odoo.sh migrations that skip versions

- Pedro is correct in saying that if we leave the migration script there, we'll have multiple versions of truth for the lower-version migration scripts, and even if it's the latest version it might still fail for all kinds of reasons

From our own experience at Therp, there is currently no "correct" way of doing multiple-versions-Enterprise-migrations with OCA modules. So we do a variety of things:

a) sometimes we deinstall the OCA module and install it back again

b) sometimes we just browse through the previous-version migration scripts of the OCA modules, and chuck excerpts of them in a custom post-migration script

c) sometimes we opt for openupgrade instead, for the reasons Pedro mentioned

d) we also tried to make a framework to go version-by-version and run each enterprise migration version by version, then downloading the db again, running OCA migrations, reuploading etc. But this is very slow, and also Odoo does not allow unsupported versions as a target version, so also not a silver bullet

I'm leaning towards Pedro on this one, because in the case that Stefan describes "for projects where there isn't that much in-depth knowledge (...) on odoo.sh" while we assume that we could help these poor consultants with less knowledge by having the migration script there, it could also well be that:

- we actually introduce new errors for them

- they opt for the hack and slash method anyway eg deinstall and install again

- they edit the module in-place for the time being and copypaste some parts of the older migration script

- they live with the incorrect datamigration, or they fix it in a manual way by exporting/reimporting data from a spreadsheet

- they decide to hire tech-savvy guys to get the oca module and perhaps some of the other breaking things over the line

etc. So while we think we may be helping them, to me it's just an assumption, which is a pretty thin argument to make a change. If it does make things messier for tech-savvy people, then not doing it may be the best option.

-Tom

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Reference