Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 54 additions & 0 deletions docsource/development.rst
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,46 @@ the full power of OpenUpgrade was unleashed to successfully overcome the
https://github.com/OCA/OpenUpgrade/pull/2275/files.


Handling of the renaming and merging of custom modules with a Custom Configuration File
---------------------------------------------------------------------------------------

To handle custom code, you can create a custom configuration file
(ex: ``openupgrade-15.conf``) which can be part of your custom repo.

This file can be used to store the renaming and merge of custom modules.
The expected content structure of the file is the following:

.. code-block:: text

[renamed_modules]
old_module_name_1=new_module_name_1
old_module_name_2=new_module_name_2
[merged_modules]
merged_module_1=new_module_merged_1

Then, you must declare this custom configuration file into your Odoo
configuration file (``odoo.cfg`` or ``odoo.conf``) like this:

.. code-block:: text

[openupgrade]
config_path=../config/openupgrade-15.conf

The purpose of using a configurable path is to allow you adding the openupgrade
custom configuration file into the repo where your custom modules are so you can commit
it.

When running the upgrade, the configurations ``renamed_modules`` and ``merged_modules``
will be taken into account as one of the first step of the migration as part of the
pre-migration script of the module ``base``:

.. code-block:: python

openupgrade.update_module_names(cr, renamed_modules.items())
openupgrade.update_module_names(cr, merged_modules.items(), merge_modules=True)



Learn from existing migration scrips
------------------------------------

Expand Down Expand Up @@ -114,6 +154,20 @@ It is available only for 12 and 13:
https://github.com/OCA/OpenUpgrade/pulls?q=is%3Apr+%5BFIX%5D+reset+exception


Re-upgrade an upgraded module
.............................

In some cases, you might want to try forcing the upgrade of a module which was already
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph is not related to this PR. Let me know if you want me to create a dedicated PR.

Copy link
Member

@StefanRijnhart StefanRijnhart Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here as well, if you want to try to reset your module versions you have to know what you are doing as it will not work unless with the simpelest of migration scripts. So telling people just to go ahead and do this is misleading.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you ever been using this trick @StefanRijnhart ?

This page is for the people who want to do development on OpenUpgrade so somehow they should know what they are doing.

Also, running migration scripts takes quite a lot of time, and I think that this trick can help during development to test faster to be able to move forward. But well, at this stage of learning about OpenUpgrade, what I think is closer to imagination rather than well thought and tested solutions.

While you have way way more experience than me in developing for OpenUpgrade... I probably should just listen to you.

Copy link
Member

@StefanRijnhart StefanRijnhart Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have only ever used this trick when I wanted to iteratively test whether minor migration scripts in custom projects do not raise syntax errors. Such simple scripts are usually reentrant, unlike the complex scripts in OpenUpgrade with their pre/post dependencies and renamed fields.
If this is to ease the development of openupgrade scripts, the trick I use is to raise an error explicitely at the end of the post migration script which rolls back the transaction so that you can safely start again after inspecting the results (in a debugger right before the raising of the exception)

upgraded by resetting the version of the module to a past version.

You might want to do that if you fix the migration script of a module after it was
migrated.

Example to update the known version of ``base`` to 14.0 so OpenUpgrade will try
to re-upgrade it to version 15:

``update ir_module_module set latest_version='14.0' where name='base';``

Learning resources
------------------

Expand Down
61 changes: 54 additions & 7 deletions openupgrade_scripts/apriori.py
Original file line number Diff line number Diff line change
@@ -1,9 +1,50 @@
""" Encode any known changes to the database here
to help the matching process
"""
import configparser as ConfigParser
import logging

import odoo


def load_custom_config():
openupgrade_config_path = odoo.tools.config.misc.get("openupgrade").get(
"config_path"
)
res = {}
if openupgrade_config_path:
logging.info("load_custom_config from %s: ", openupgrade_config_path)
p = ConfigParser.RawConfigParser()
try:
p.read([openupgrade_config_path])
for sec in p.sections():
res.setdefault(sec, {})
for (name, value) in p.items(sec):
if value == "True" or value == "true":
value = True
if value == "False" or value == "false":
value = False
res[sec][name] = value
except IOError:
pass
except ConfigParser.NoSectionError:
pass
else:
logging.info("load_custom_config, openupgrade_config_path not set")

return res


custom_config = load_custom_config()


def _get(config_name, config_base):
return config_base | custom_config.get(config_name, {})


# ######################################################################################
# Encode any known changes to the database here to help the matching process
# ######################################################################################

# Renamed modules is a mapping from old module name to new module name
renamed_modules = {
_renamed_modules = {
# odoo
"crm_iap_lead": "crm_iap_mine",
"crm_iap_lead_enrich": "crm_iap_enrich",
Expand All @@ -13,9 +54,11 @@
# OCA/...
}

renamed_modules = _get("renamed_modules", _renamed_modules)

# Merged modules contain a mapping from old module names to other,
# preexisting module names
merged_modules = {
_merged_modules = {
# odoo
"account_edi_extended": "account_edi",
"l10n_be_invoice_bba": "l10n_be",
Expand All @@ -30,11 +73,15 @@
# OCA/...
}

merged_modules = _get("merged_modules", _merged_modules)

# only used here for upgrade_analysis
renamed_models = {
_renamed_models = {
# odoo
# OCA/...
}
renamed_models = _get("renamed_models", _renamed_models)

# only used here for upgrade_analysis
merged_models = {}
_merged_models = {}
merged_models = _get("merged_models", _merged_models)