Archives
Contributors
-
Show count of versions in documents app
Hello together,
in the documents app kanban view I want to show the count of versions for this document if more than 1 version of this document exists. I try several ways to implement that logic but I do not get it. How is the logic between documents.document and ir.attachment. I do not find id’s or keys to connect this two modells and in some cases I didn’t get a dataset in ir_attachment for the version.
Thanks a lot.
Best regards,
Matthias
Matthias Ellmerer
digitalisierung & software
📍 Sonnendorf 33a, 6334 Schwoich | Austria
📞 +43 664 353 87 33 · 🌐 implema.at
by Matthias Ellmerer - 01:30 - 7 May 2025 -
Re: Removal of migration scripts on each new version
I prefer to remove the scripts.The reason is simple, it is safer.Keeping them might work in some cases, but it might be problematic in others. It is true that as a community, we don't want to make life harder for community or enterprise developers. However, our duty is to deliver the safest option.We cannot ask a developer to take into account if this change might affect when coming from 12 or 13 or 14 or.... it is easier to take into account just the current version.I understand that in some specific cases, with a strong maintainer behind the project, it might have sense, but not as a rule.Also, with the latest versions (with the scripts folder) it might be easy to create an aggregator of scripts. If you want, we can do a work table on this topic on the next OCA Days (On Belgium or in Spain)My 2 cents.El mié, 7 may 2025 a las 12:27, Sebastien Alix (<notifications@odoo-community.org>) escribió:Hello,
Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:
- often `pre` scripts can run without adaptation (that could
happen of course with all reasons written by Pedro above), as
they normally only rely on SQL
- `post` ones that are using Odoo ORM can be broken easily (i.e.
invoking a 16.0 post script with an 18.0 Odoo code base), and
therefore requires modifications (making such script idempotent
will require extra work from contributors if we go that way)
To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.
=> often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
=> from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of installed OCA modules
=> its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...
Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).
That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?
Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
Hi,
the migration guide mandates the following
> Remove any possible migration script from previous version (in a nutshell, removemigrationsfolder inside the module if exists).
(https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)
However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.
I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.
My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).
Can I have a temperature check from the community to see how you all feel about this?
Best 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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Sébastien Alix Business Solutions Odoo Developer Camptocamp France SA https://www.camptocamp.com/
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 12:51 - 7 May 2025 - often `pre` scripts can run without adaptation (that could
happen of course with all reasons written by Pedro above), as
they normally only rely on SQL
-
Re: Removal of migration scripts on each new version
Hello,
Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:
- often `pre` scripts can run without adaptation (that could
happen of course with all reasons written by Pedro above), as
they normally only rely on SQL
- `post` ones that are using Odoo ORM can be broken easily (i.e.
invoking a 16.0 post script with an 18.0 Odoo code base), and
therefore requires modifications (making such script idempotent
will require extra work from contributors if we go that way)
To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.
=> often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
=> from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of installed OCA modules
=> its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...
Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).
That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?
Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
Hi,
the migration guide mandates the following
> Remove any possible migration script from previous version (in a nutshell, removemigrationsfolder inside the module if exists).
(https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)
However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.
I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.
My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).
Can I have a temperature check from the community to see how you all feel about this?
Best 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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- Sébastien Alix Business Solutions Odoo Developer Camptocamp France SA https://www.camptocamp.com/
by Sébastien Alix - 12:26 - 7 May 2025 - often `pre` scripts can run without adaptation (that could
happen of course with all reasons written by Pedro above), as
they normally only rely on SQL
-
Re: Removal of migration scripts on each new version
As a maintainer I would like to have the liberty of keeping the migration scripts if I want to, as I think it is a good service to provide to my users.In the modules I help maintaining it is usually not a problem nor difficulty. For instance in mis_builder and queue_job It's likely that we could have all the scripts for the past 8 versions run on the latest.So I don't quite understand why it is forbidden to keep them. If I want to take responsibility for maintaining them I should be allowed to do so.Best regards,-StéphaneOn Wed, May 7, 2025 at 11:42 AM Raphaël Reverdy <notifications@odoo-community.org> wrote:Hello,With our existing OCA tools and processes, I think it's better to remove migrations scripts from previous versions.back/forwarding changes across different versions is already a boring and time consuming task.Doing the same for not testable-on-CI and hard-to-review migrations scripts ? I doubt it will be consistently done.Running migration with openupgrade alone or Odoo EE + openupgrade for each version looks to be the safest way.RaphLe mer. 7 mai 2025 à 08:56, Tom Blauwendraat <notifications@odoo-community.org> a écrit :On 5/6/25 23:27, Tom Blauwendraat wrote: > (...) 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. I wanted to add to this that -if- some of the Enterprise-heavy OCA member companies (Ad-Hoc, Camptocamp, Acsone etc) have a convincing argument why this is really helpful to them, I would weigh that argument heavier than what Openupgrade-heavy companies would say about it. After all, it does not break Openupgrade.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ReverdyMobile +33 6 38 02 03 93Fixe +33 4 82 53 84 60_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 12:11 - 7 May 2025 -
Re: Removal of migration scripts on each new version
+1 pedro y stefan.I believe this topic has been discussed more than once. It would be interesting to indicate the decision made and the reasoning behind it, to avoid having to deal with it every year.El mié, 7 may 2025 a las 11:42, Raphaël Reverdy (<notifications@odoo-community.org>) escribió:Hello,With our existing OCA tools and processes, I think it's better to remove migrations scripts from previous versions.back/forwarding changes across different versions is already a boring and time consuming task.Doing the same for not testable-on-CI and hard-to-review migrations scripts ? I doubt it will be consistently done.Running migration with openupgrade alone or Odoo EE + openupgrade for each version looks to be the safest way.RaphLe mer. 7 mai 2025 à 08:56, Tom Blauwendraat <notifications@odoo-community.org> a écrit :On 5/6/25 23:27, Tom Blauwendraat wrote: > (...) 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. I wanted to add to this that -if- some of the Enterprise-heavy OCA member companies (Ad-Hoc, Camptocamp, Acsone etc) have a convincing argument why this is really helpful to them, I would weigh that argument heavier than what Openupgrade-heavy companies would say about it. After all, it does not break Openupgrade.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ReverdyMobile +33 6 38 02 03 93Fixe +33 4 82 53 84 60_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 613 04 66 67 
valentin.vinagre@sygel.es 
https://www.sygel.es 
C/ Àlaba 61, 5ª planta, 08005, Barcelona
by Valentín Vinagre - 12:01 - 7 May 2025 -
Re: Removal of migration scripts on each new version
Hello,With our existing OCA tools and processes, I think it's better to remove migrations scripts from previous versions.back/forwarding changes across different versions is already a boring and time consuming task.Doing the same for not testable-on-CI and hard-to-review migrations scripts ? I doubt it will be consistently done.Running migration with openupgrade alone or Odoo EE + openupgrade for each version looks to be the safest way.RaphLe mer. 7 mai 2025 à 08:56, Tom Blauwendraat <notifications@odoo-community.org> a écrit :On 5/6/25 23:27, Tom Blauwendraat wrote: > (...) 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. I wanted to add to this that -if- some of the Enterprise-heavy OCA member companies (Ad-Hoc, Camptocamp, Acsone etc) have a convincing argument why this is really helpful to them, I would weigh that argument heavier than what Openupgrade-heavy companies would say about it. After all, it does not break Openupgrade.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ReverdyMobile +33 6 38 02 03 93Fixe +33 4 82 53 84 60
by Raphaël Reverdy - 11:41 - 7 May 2025 -
Re: Large Data Files
Sorry for the wrong urlHere is the good oneLe mer. 7 mai 2025 à 10:16, David Beal <david.beal@akretion.com> a écrit :Hi Jérome,Additionally you may reach more performance with https://github.com/yanyanren123hotmailcom/connectorxHere is the explanationI experimented successfully connectorx with polars (but not benchmark it myself with other solutions)RegardsLe ven. 2 mai 2025 à 23:57, Jerôme Dewandre <notifications@odoo-community.org> a écrit :Hello everyone,
Thanks to your valuable feedback and suggestions, I’ve developed a dedicated ETL module for Odoo designed to handle large-scale data synchronization efficiently.
The solution bypasses ORM bottlenecks using optimized SQL and batch processing, and integrates Polars and SQLAlchemy for fast data transformation.
It supports millions of records and is ideal for daily sync with legacy systems (from SQLITE for now).
The module is available here: https://github.com/cyberwave-odoo/odoo-etl
I truly appreciate the community insights that shaped this project — thank you!
Best regards,
Jérôme
On Wed, Aug 21, 2024 at 9:17 AM David Beal <notifications@odoo-community.org> wrote:Nice to see pandas run fast.For those for those that want run very very ... very fast consider to use polarsLe mer. 21 août 2024 à 01:57, Graeme Gellatly <notifications@odoo-community.org> a écrit :Queue job and batching can work. It is commonplace. But if it is CPU/Memory then honestly, after optimising what you can within the framework (e.g. as per Holger) a lot of the time you just get away with running a seperate worker on a separate port for long running jobs and set the limits/timeouts high. That is how a lot of people deploy cron workers these days and in older Odoo we used to have to do it to run financial reports and seemingly again now. 30,000 simple records is not so much.There may also be some db tuning you can do around WAL files, checkpoints etc if they get in the way.On Wed, Aug 21, 2024 at 9:57 AM Jerôme Dewandre <notifications@odoo-community.org> wrote:Hello,Thank you very much for your quick responses :)
Tom Blauwendraat: I am running on v16Holger Brunn: adapting the script with .with_context(tracking_disable=True) to Disable email notification divides the running time by at least 4
Goran Sunjka: It is indeed an interesting idea, I was wondering if I could store a hash of the row in Postgres to check if an existing record was updated to separate "create" and "update" action
Daniel Reis: This is indeed the problem I encountered.
Thank you all for your replies, it helps a lot :)JérômeOn Tue, Aug 20, 2024 at 7:47 PM Daniel Reis <notifications@odoo-community.org> wrote:I would expect this code to just abort for a non trivial quantity of records.
The reason why is that this is a single worker doing a single database transaction.
So the worker process will probably hit the time and CPU limits and be killed, and no records would be saved because of a transaction rollback.
And if you increase those limits a lot, you will probably cause long table locks on the database, and hurt other users and processes.
Going direct to the database can work if the data is pretty simple.
It can work but it can also be a can of worms.
One approach is to have an incremental approach to the data loading.
In the past I have used external ETL tools or scripts to do this.
Keeping it inside Odoo, one of the tools that can help is the Job Queue, possibly along with something like base_import_async:
https://github.com/OCA/queue/tree/16.0/base_import_async
Thanks
--
DANIEL REIS
MANAGING PARTNERMeet with me.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais![[Logo OpenSourceIntegrators.com]](https://www.opensourceintegrators.com/images/opensource-logo-2022.svg)
On 20/08/2024 16:32, Jerôme Dewandre wrote:
Hello,
I am currently working on a syncro with a legacy system (adesoft) containing a large amount of data that must be synchronized on a daily basis (such as meetings).
It seems everything starts getting slow when I import 30.000 records with the conventional "create()" method.
I suppose the ORM might be an issue here. Potential workaround:
1. Bypass the ORM to create a record with self.env.cr.execute (but if I want to delete them I will also need a custom query)2. Bypass the ORM with stored procedures (https://www.postgresql.org/docs/current/sql-createprocedure.html)3. Increase the CPU/RAM/Worker nodes4. Some better ideas?
What would be the best way to go?
A piece of my current test (df is a pandas dataframe containing the new events):
@api.modeldef create_events_from_df(self, df):Event = self.env['event.event']events_data = []for _, row in df.iterrows():event_data = {'location': row['location'],'name': row['name'],'date_begin': row['date_begin'],'date_end': row['date_end'],}events_data.append(event_data)# Create all events in a single batchEvent.create(events_data)
Thanks in advance if you read this, and thanks again if you replied :)
Jérôme_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by David BEAL - 10:26 - 7 May 2025 -
Re: Large Data Files
Hi Jérome,Additionally you may reach more performance with https://github.com/yanyanren123hotmailcom/connectorxHere is the explanationI experimented successfully connectorx with polars (but not benchmark it myself with other solutions)RegardsLe ven. 2 mai 2025 à 23:57, Jerôme Dewandre <notifications@odoo-community.org> a écrit :
Hello everyone,
Thanks to your valuable feedback and suggestions, I’ve developed a dedicated ETL module for Odoo designed to handle large-scale data synchronization efficiently.
The solution bypasses ORM bottlenecks using optimized SQL and batch processing, and integrates Polars and SQLAlchemy for fast data transformation.
It supports millions of records and is ideal for daily sync with legacy systems (from SQLITE for now).
The module is available here: https://github.com/cyberwave-odoo/odoo-etl
I truly appreciate the community insights that shaped this project — thank you!
Best regards,
Jérôme
On Wed, Aug 21, 2024 at 9:17 AM David Beal <notifications@odoo-community.org> wrote:Nice to see pandas run fast.For those for those that want run very very ... very fast consider to use polarsLe mer. 21 août 2024 à 01:57, Graeme Gellatly <notifications@odoo-community.org> a écrit :Queue job and batching can work. It is commonplace. But if it is CPU/Memory then honestly, after optimising what you can within the framework (e.g. as per Holger) a lot of the time you just get away with running a seperate worker on a separate port for long running jobs and set the limits/timeouts high. That is how a lot of people deploy cron workers these days and in older Odoo we used to have to do it to run financial reports and seemingly again now. 30,000 simple records is not so much.There may also be some db tuning you can do around WAL files, checkpoints etc if they get in the way.On Wed, Aug 21, 2024 at 9:57 AM Jerôme Dewandre <notifications@odoo-community.org> wrote:Hello,Thank you very much for your quick responses :)
Tom Blauwendraat: I am running on v16Holger Brunn: adapting the script with .with_context(tracking_disable=True) to Disable email notification divides the running time by at least 4
Goran Sunjka: It is indeed an interesting idea, I was wondering if I could store a hash of the row in Postgres to check if an existing record was updated to separate "create" and "update" action
Daniel Reis: This is indeed the problem I encountered.
Thank you all for your replies, it helps a lot :)JérômeOn Tue, Aug 20, 2024 at 7:47 PM Daniel Reis <notifications@odoo-community.org> wrote:I would expect this code to just abort for a non trivial quantity of records.
The reason why is that this is a single worker doing a single database transaction.
So the worker process will probably hit the time and CPU limits and be killed, and no records would be saved because of a transaction rollback.
And if you increase those limits a lot, you will probably cause long table locks on the database, and hurt other users and processes.
Going direct to the database can work if the data is pretty simple.
It can work but it can also be a can of worms.
One approach is to have an incremental approach to the data loading.
In the past I have used external ETL tools or scripts to do this.
Keeping it inside Odoo, one of the tools that can help is the Job Queue, possibly along with something like base_import_async:
https://github.com/OCA/queue/tree/16.0/base_import_async
Thanks
--
DANIEL REIS
MANAGING PARTNERMeet with me.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
On 20/08/2024 16:32, Jerôme Dewandre wrote:
Hello,
I am currently working on a syncro with a legacy system (adesoft) containing a large amount of data that must be synchronized on a daily basis (such as meetings).
It seems everything starts getting slow when I import 30.000 records with the conventional "create()" method.
I suppose the ORM might be an issue here. Potential workaround:
1. Bypass the ORM to create a record with self.env.cr.execute (but if I want to delete them I will also need a custom query)2. Bypass the ORM with stored procedures (https://www.postgresql.org/docs/current/sql-createprocedure.html)3. Increase the CPU/RAM/Worker nodes4. Some better ideas?
What would be the best way to go?
A piece of my current test (df is a pandas dataframe containing the new events):
@api.modeldef create_events_from_df(self, df):Event = self.env['event.event']events_data = []for _, row in df.iterrows():event_data = {'location': row['location'],'name': row['name'],'date_begin': row['date_begin'],'date_end': row['date_end'],}events_data.append(event_data)# Create all events in a single batchEvent.create(events_data)
Thanks in advance if you read this, and thanks again if you replied :)
Jérôme_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by David BEAL - 10:21 - 7 May 2025 -
Fwd: Crowdfunding module
Hi everyone, Please your attention to the following repo that we want to create, in order to support an OCA board initiative where we want to make it easier for contributors to crowdfund module development, or Openupgrade development, like was talked about often in the past at OCA days. https://github.com/OCA/repo-maintainer-conf/pull/89 -Tom
by Tom Blauwendraat - 09:01 - 7 May 2025 -
Re: Removal of migration scripts on each new version
On 5/6/25 23:27, Tom Blauwendraat wrote: > (...) 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. I wanted to add to this that -if- some of the Enterprise-heavy OCA member companies (Ad-Hoc, Camptocamp, Acsone etc) have a convincing argument why this is really helpful to them, I would weigh that argument heavier than what Openupgrade-heavy companies would say about it. After all, it does not break Openupgrade.
by Tom Blauwendraat - 08:55 - 7 May 2025 -
Re: Removal of migration scripts on each new version
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
by Graeme Gellatly - 12:31 - 7 May 2025 -
Re: Removal of migration scripts on each new version
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
by Tom Blauwendraat - 11:26 - 6 May 2025 -
Re: Removal of migration scripts on each new version
Stefan, all your suggestions seem to overcomplicate the general management of the migrations, although you say it doesn't mean anything for openupgraders. If we allow this, pull requests will be filled by petitions around migration scripts. You should consider the creation of such a tool that gathers the corresponding migration scripts across versions. That is IMO the definitive way of dealing with this, as if not having half migration scripts is not the solution, as in the end, the migration is incorrect. And worst, the missing bits may pass unnoticed. Not having anything migrated leads to checking what's going on and then doing it the right way.> 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.> Well, even handling such a tool is a lot of effort, requiring at least a fork of all the OCA projectsThis can be done through GitHub API (check for example some API and file manipulation in https://github.com/OCA/maintainer-tools/blob/master/tools/migrate_branch_empty.py), but I agree it requires some effort.> 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.I insist that this won't be true a lot of times due to crashes or half-baked data that seems to be OK, but they are not. I have rescued several projects from others with not "much in-depth knowledge", and it's a hell to straighten the instance. I can't imagine what would be to deal with inconsistent DBs due to this...> It sounds like you are defending the policy so as to discourage the use of the enterprise migration service.Well, I put "IMO" on purpose to say that it's my opinion, but it's an opinion consolidated across multiple attempts of using enterprise migration service with a lot of pain. That's why I recommend using it only if you don't use anything extra, as if not, the time spent getting a functional migration is higher than using OpenUpgrade (this once you get over the initial entry barrier).Regards.
by Pedro M. Baeza - 08:35 - 6 May 2025 -
Re: Removal of migration scripts on each new version
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
by Stefan Rijnhart - 08:06 - 6 May 2025 -
Re: Removal of migration scripts on each new version
Hi Stefan and others,
I think Pedro's argument sound quite convincing, so maybe I was to quick with my support.
Stefan, what would be your counter arguments?
Kind regards, Ronald
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).
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.
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:
- 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.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Ronald Portier - 05:46 - 6 May 2025 -
Re: Removal of migration scripts on each new version
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 being 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).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.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:- 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 to 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/340e44234a165769115bc954120bfcde5dd7b74e/account_payment_partner/migrations/13.0.1.0.0/post-migration.py#L15So, 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.Regards.
by Pedro M. Baeza - 04:21 - 6 May 2025 -
Re: Removal of migration scripts on each new version
+1 To keep the migration scripts.
They also provide some kind of documentation or insight in what has changed since past versions.
Kind regards, Ronald
On 06-05-2025 13:02, Stefan Rijnhart wrote:
Hi,
the migration guide mandates the following
> Remove any possible migration script from previous version (in a nutshell, removemigrationsfolder inside the module if exists).
(https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)
However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.
I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.
My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).
Can I have a temperature check from the community to see how you all feel about this?
Best 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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Ronald Portier - 04:10 - 6 May 2025 -
Re: Removal of migration scripts on each new version
Hi Stefan,I think that your rationale on this is spot on.You have my vote!+1Cheers,PetarOn Tue, May 6, 2025 at 1:02 PM Stefan Rijnhart <notifications@odoo-community.org> wrote:Hi,
the migration guide mandates the following
> Remove any possible migration script from previous version (in a nutshell, removemigrationsfolder inside the module if exists).
(https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)
However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.
I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.
My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).
Can I have a temperature check from the community to see how you all feel about this?
Best 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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Petar Najman - 04:10 - 6 May 2025 -
Re: Removal of migration scripts on each new version
On 06-05-2025 15:22, Sergio Corato wrote:
Il giorno mar 6 mag 2025 alle ore 14:27 Stefan Rijnhart <notifications@odoo-community.org> ha scritto:
On 06-05-2025 14:17, Juan José Scarafía wrote: > there. If you *are* updating version by version, those older scripts > just won't run anyway, right? That is correct, if you migrate from 17 to 18, any 16.0.x.x.x migration script will not be triggered.
This will happen only if the "version" variable in the script is checked?
No, the version variable passed to each script does not need to be checked. It is the Odoo migration manager that filters out the scripts by the versions indicated in the directory names: https://github.com/odoo/odoo/blob/18.0/odoo/modules/migration.py#L203-L216
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
by Stefan Rijnhart - 03:37 - 6 May 2025 -
Re: Removal of migration scripts on each new version
Sergio CoratoIl giorno mar 6 mag 2025 alle ore 14:27 Stefan Rijnhart <notifications@odoo-community.org> ha scritto:On 06-05-2025 14:17, Juan José Scarafía wrote: > I agree, keeping the migration scripts probably doesn't mean you can > just skip versions and expect them to run flawlessly, but in a lot of > cases, it does seem to work out just fine. Well, they should run flawlessly otherwise it will break everyone's migration. The scripts that we keep should be idempotent and not be invalidated by subsequent data model changes. So special care should be taken when reviewing PRs that contain older scripts. > On the other hand, I'm not really seeing any downside to leaving them > there. If you *are* updating version by version, those older scripts > just won't run anyway, right? That is correct, if you migrate from 17 to 18, any 16.0.x.x.x migration script will not be triggered.
This will happen only if the "version" variable in the script is checked?-- 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_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sergio Corato - 03:21 - 6 May 2025
