升级定制数据库

升级到 Odoo 新版本可能具有挑战性，尤其是当您使用的数据库包含自定义模块时。本页的目的是解释使用定制模块升级数据库的技术流程。有关如何在不使用自定义模块的情况下升级数据库的指南，请参阅 Upgrade documentation。

我们考虑自定义模块，即扩展 Odoo 标准代码且不是使用 Studio 应用程序构建的任何模块。在升级此类模块之前，或在请求升级之前，请查看 服务水平协议（SLA） 以确保由谁负责。

在进行我们所说的数据库的**自定义升级**时，请记住升级的目标：

  1. 保持支持

  2. 获取最新功能

  3. 享受性能提升

  4. 减少技术债务

  5. 从安全改进中受益

Odoo 的每个新版本都会引入更改。这些更改可能会影响已开发定制的模块。这就是升级包含自定义模块的数据库需要额外步骤才能升级源代码的原因。

升级自定义数据库应遵循以下步骤：

  1. Stop the developments and challenge them。

  2. Request an upgraded database。

  3. Make your module installable on an empty database。

  4. Make your module installable on the upgraded database。

  5. Test extensively and do a rehearsal。

  6. Upgrade the production database。

第一步：停止事态发展

开始升级需要承诺和开发资源。如果同时进行开发，那么每次更改这些功能时都需要重新升级和测试。这就是为什么我们建议在开始升级过程时完全冻结代码库。不用说，错误修复不受此建议的约束。

停止开发后，最好评估所做的开发并将其与当前版本和目标版本之间引入的功能进行比较。尽可能地挑战发展并找到实用的解决方法。消除您的开发与 Odoo 标准版本之间的冗余将简化升级过程并减少技术债务。

注解

您可以在 Release Notes 中找到有关版本之间更改的信息。

第 2 步：请求升级数据库

一旦自定义模块的开发停止并且已实现的功能面临删除冗余和不必要代码的挑战，下一步就是请求升级测试数据库。为此，请按照 获取升级后的测试数据库 中提到的步骤操作，具体取决于数据库的托管类型。

此阶段的目的不是开始使用升级后的数据库中的自定义模块，而是确保标准升级过程无缝运行，并正确交付测试数据库。如果情况并非如此，并且升级请求失败，请通过 support page 选择与测试升级相关的选项来请求 Odoo 的帮助。

第 3 步：清空数据库

在处理升级的测试数据库之前，我们建议在升级的目标版本中的空数据库上进行自定义开发。这确保了定制与新版本的 Odoo 兼容，允许分析它的行为方式以及与新功能的交互方式，并保证它们在升级数据库时不会导致任何问题。

使自定义模块在空数据库中工作还有助于避免生产数据库中可能存在的更改和错误配置（例如工作室自定义、自定义网站页面、电子邮件模板或翻译）。它们本质上与自定义模块没有关系，因此可能会在升级过程的此阶段引发不必要的问题。

要使自定义模块在空数据库上工作，我们建议遵循以下步骤：

  1. 使自定义模块可安装

  2. 测试和修复

  3. 清理代码

  4. Make standard tests run successfully

使自定义模块可安装

第一步是使自定义模块可安装在新的 Odoo 版本中。这意味着，首先要确保安装过程中没有回溯或警告。为此，将自定义模块一一安装在新 Odoo 版本的空数据库中，并修复由此产生的回溯和警告。

此过程将有助于检测模块安装过程中的问题。例如：

  • 无效的模块依赖项。

  • 语法更改：资产声明、OWL 更新、属性。

  • 对不再存在或重命名的标准字段、模型、视图的引用。

  • 已从视图中移动或删除的 Xpath。

  • 方法被重命名或删除。

  • …

测试和修复

一旦安装模块时不再有回溯，下一步就是测试它们。即使自定义模块可安装在空数据库上，也不能保证其执行期间不会出现错误。因此，我们鼓励彻底测试所有定制，以确保一切都按预期工作。

此过程将有助于检测模块安装期间未识别且只能在运行时检测到的进一步问题。例如，已弃用对标准 python 或 OWL 函数的调用、对标准字段不存在的引用等。

我们建议测试所有自定义，尤其是以下元素：

  • 意见

  • 电子邮件模板

  • 报告

  • 服务器操作和自动操作

  • 标准工作流程的变化

  • 计算字段

我们还鼓励编写自动化测试，以节省测试迭代期间的时间，增加测试覆盖率，并确保引入的更改和修复不会破坏现有流程。如果自定义中已经实现了测试，请确保它们升级到新的 Odoo 版本并成功运行，修复可能存在的问题。

清理代码

在升级过程的这个阶段，我们还建议尽可能清理代码。这包括：

  • 删除多余和不必要的代码。

  • 删除现在属于 Odoo 标准一部分的功能，如 第一步：停止事态发展 中所述。

  • 如果不再需要，请清理注释代码。

  • 如果需要，重构代码（函数、字段、视图、报告等）。

标准测试

完成前面的步骤后，我们建议确保与自定义模块的依赖项相关的所有标准测试都通过。标准测试确保代码逻辑的验证并防止数据损坏。它们将帮助您在处理数据库之前识别错误或不需要的行为。

如果出现标准测试失败的情况，我们建议分析其失败的原因：

  • 定制改变了标准工作流程：使标准测试适应您的工作流程。

  • 自定义没有考虑特殊流程：调整您的自定义以确保它适用于所有标准工作流程。

第四步：升级数据库

一旦自定义模块可安装并在空数据库中正常工作，就可以让它们在 upgraded database 上工作。

为了确保自定义代码在新版本中完美运行，请按照以下步骤操作：

迁移数据

在自定义模块的升级过程中，您可能必须使用 upgrade scripts 来反映源代码对其相应数据的更改。与升级脚本一起，您还可以使用 升级实用程序 及其辅助函数。

  • 在自定义代码升级期间重命名的任何技术数据（模型、字段、外部标识符）都应使用升级脚本重命名，以避免模块升级期间数据丢失。另请参阅：rename_field()、rename_model()、rename_xmlid()。

  • 在标准升级过程中从新 Odoo 版本的源代码和数据库中删除的标准模型中的数据可能需要从旧模型表中恢复（如果旧模型表仍然存在）。

    Example

    模型“sale.subscription` are not automatically migrated from Odoo 15 to Odoo 16 (when the model was merged into sale.order). In this case, a SQL query can be executed on an upgrade script to move the data from one table to the other. Take into account that all columns/fields must already exist, so consider doing this in a ``post-”脚本的自定义字段（请参阅:ref:`upgrade-scripts/phases）。

    def migrate(cr, version):
   cr.execute(
      """
      UPDATE sale_order so
         SET custom_field = ss.custom_field
        FROM sale_subscription ss
       WHERE ss.new_sale_order_id = so.id
      """
   )

    查看文档以获取有关 升级脚本 的更多信息。

升级脚本还可用于：

  • 缩短升级的处理时间。例如，通过使用 SQL 查询来存储记录数量过多的模型上的计算存储字段的值。

  • 如果字段值的计算发生变化，请重新计算字段。另请参见 recompute_fields()。

  • 卸载不需要的自定义模块。另请参见 remove_module()。

  • 纠正错误的数据或错误的配置。

运行和测试升级脚本

由于 Odoo Online 数据库不允许安装包含 Python 文件的自定义模块，因此无法在此平台上运行升级脚本。

测试自定义模块

为了确保自定义模块能够与升级后的数据库中的数据正常工作，还需要对它们进行测试。这有助于确保数据库中存储的标准数据和自定义数据保持一致，并且在升级过程中不会丢失任何内容。

注意事项：

  • 视图不起作用：在升级过程中，如果视图因其内容而导致问题，它将被禁用。您可以在升级报告中找到有关禁用视图的信息。 This view needs to be activated again (or removed if not useful anymore).为此，我们建议使用升级脚本。

  • Module data 未更新：在新数据库中升级模块时，具有“noupdate”标志的自定义记录不会更新。对于因新版本变化而需要更新的自定义数据，我们建议使用升级脚本来完成。另请参阅：update_record_from_xml()。

第五步：测试和排练

When the custom modules are working properly in the upgraded database, it is crucial to do another round of testing to assess the database usability and detect any issues that might have gone unnoticed in previous tests.有关测试升级数据库的更多信息，请检查 测试新版数据库。

正如 升级生产数据库 中提到的，标准升级脚本和数据库都在不断发展。因此，强烈建议经常请求新的升级测试数据库，并确保升级过程仍然成功。

除此之外，在升级生产数据库的前一天对升级过程进行全面演练，以避免升级过程中出现不良行为，并检测迁移数据可能出现的任何问题。

第6步：生产升级

一旦您对升级生产数据库有信心，请按照 升级生产数据库 中描述的过程进行操作，具体取决于数据库的托管类型。