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
Opener B.V., Stefan Rijnhart
- 06/05/2025 20:03:17
On 06-05-2025 16:22, Pedro M. Baeza wrote:
Although you can think at the beginning that there's no problem keeping the previous migration scripts on each version, there are tons of reasons for not doing it. First of all, it creates on people seeing that migration scripts the false sensation that they don't have to look in any other place for migrating between several versions except on the latest one, while there can happen a lot of things:

- At the moment you are rescuing the commit history to make the migration, the migration scripts for the previous version may still not be developed/merged, and they are incorporated later, so the latest version won't have these migration scripts while they are needed. And you can't demand "openupgraders" to do forward-ports of the migration scripts to each upper version.
- The initial migration scripts may be incorrect or incomplete, and there can be several patches later after upper versions were be ing fetched and migrated. This is even worse IMO, as you think you have the right migration scripts, while they are not the good ones. And again you can't demand the contributors to duplicate the work propagating the patch on the migration scripts (or well, being dreamer thinking that people are going to do it if you state that in the guidelines).


So, if it is the case that some of the scripts might require maintenance incidentally, surely that's better than not having the script at all as it would lead to data loss? It's likely this maintenance will be picked up by the people who benefit from using the scripts in the way I described, so nothing is demanded from openupgraders. The openupgraders aren't even going to notice as they run the migration of each version in sequence.

That's why the saner option is to purge these migration scripts from upper versions to only have one source of truth, and this is independent of the type of migration scripts. Stefan states "if they are safe for inclusion in the later version", but that's something very difficult to be judged, specially for the migrators/reviewers which are not used to these migration scripts, so another reason for not having grey areas: you follow the same rule of not having them, as in the end, you have to check the same if they are outdated or missing, etc, etc.

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

If you do enterprise migrations jumping several versions, you should develop a tool to gather all the migration scripts from the intermediate versions and collect them together. Such tools may be shared and developed collaboratively for those interested. Anyway, take into account that there are a lot of reasons for these migration scripts (being gathered by the tool or being preserved through versions) to fail:

Well, even handling such a tool is a lot of effort, requiring at least a fork of all the OCA projects in use plus the knowledge to run such a tool. Instead, by keeping the migration scripts for a number of versions, we can make life easier for projects where there isn't that much in-depth knowledge. There are probably a lot of these projects on Odoo.sh. In such projects, OCA branches are likely added as submodules (there is a UI for that). There doesn't even have to be a customer fork of the OCA repos. Just imagine a project like that queue_job installed on their 17.0 database. If they migrate to 19.0 next year using the Odoo migration service, they might just find the column types of their job table messed up. The OCA can help them, basically, by not doing anything. The consultant or developer running that project doesn't have to do anything. We just have to not delete this migration script: https://github.com/OCA/queue/blob/18.0/queue_job/migrations/18.0.1.0.0/pre-migrate.py.

- They expect a specific data model state, based on the version. For example, you may have a migration script that is expecting a column that is declared in version 15, but later in 16, it disappears. If you migrate from 14 to 16, and you run that 15.0 script after having the enterprise migration done up to 16, and with the 16.0 OCA module, it will fail.
- They are also based on the stage of the update process (you have pre, post and end migration scripts). If you execute for example a pre-migration script renaming/creating a column in that phase, and it's already created due to regular update, it will crash. Some said in the past to put protections ("if" sentences checking if the column exists, and so on), but apart from over-complicating the code of migration scripts (and again, you can't demand openupgraders to do or review that job - and imagine if you have to spread it across all versions... -), it doesn't guarantee that the data will be consistent, as there can be a lot of combinations, as much as the source and target version combinations.
- Enterprise migration scripts "clean" the obsolete columns, tables, etc, making sometimes impossible t o rebuild your connections for extra data, links, etc. OpenUpgrade/OCA migration scripts count with the obsolete columns/tables are still there for doing SQLs and other actions, so another possible reason to fail.
- A variant of the previous point: some scripts are developed counting with some specific columns created on the fly or renamed for doing the actions. Example: on the 13.0 migration, we created the columns old_invoice_id in account.move and old_invoice_line_id in account.move.line to point to the old account.invoice and account.invoice.line records, and most of the OCA modules adding fields on the invoice, require these fields for transferring data from one model to the other: https://github.com/OCA/bank-payment/blob/340e44234a165769115bc954120bfcde5dd7b 74e/account_payment_partner/migrations/13.0.1.0.0/post-migration.py#L15

So, in summary, IMO, Odoo enterprise migration service should only be used if you don't have any extra modules in your DB. Once you are using OCA modules, go OpenUpgrade way, or you will spend more time reviewing all of these corner cases than doing it with OpenUpgrade. And if you are not happy with the availability date for OpenUpgrade new versions, help funding its development.


It sounds like you are defending the policy so as to discourage the use of the enterprise migration service. As the person who designed the original version of OpenUpgrade 13 years ago, I wish it all the good fortune in the world but the harsh reality is that the Odoo enterprise license is a good offer for many Odoo projects, and the migration service that comes with it does a good job for its users. Openupgrade couldn't even legally provide the scripts for the enterprise modules because of their restrictive license.

Years ago, this community decided not to block the use of OCA modules in enterprise databases, and the coexistence of the 'open core' version of Odoo with the open source modules from the OCA has been mutually beneficial ever since. I think in the spirit of that coexistence we should allow the migration scripts to be managed in a way that works for Odoo enterprise users as well, and not only for OpenUpgrade users.

Regards,
Stefan


-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail: stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web: https://opener.amsterdam

Reference