升级私有云Odoo数据库

升级到新版本的 Odoo 可能颇具挑战，尤其是当您使用的数据库包含自定义模块时。本页旨在说明升级带有定制模块的数据库的技术流程。有关如何升级不含自定义模块的数据库的指导，请参阅 升级文档。

我们将任何扩展 Odoo 标准代码且并非使用 Studio 应用构建的模块视为自定义模块。在升级此类模块之前，或在请求升级之前，请查看 服务水平协议（SLA），以确认由谁负责。

在处理我们称为数据库 自定义升级 的工作时，请牢记升级的目标：

1. 持续获得支持

2. 获取最新功能

3. 享受性能提升

4. 减少技术债务

5. 受益于安全改进

每个新版本的 Odoo 都会引入变更。这些变更可能影响已在其上开发了自定义功能的模块。因此，升级包含自定义模块的数据库需要额外步骤来升级源代码。

升级定制数据库需遵循以下步骤：

1. 停止定制开发并对其进行审视。

2. 申请升级后的数据库。

3. 使模块可安装在空数据库上。

4. 使模块可安装在升级后的数据库上。

5. 充分测试并进行演练。

6. 升级生产数据库。

步骤 1：停止开发

开始升级需要投入精力和开发资源。如果同时继续进行开发，那么每次修改这些功能时，都需要重新升级并测试。因此，我们建议在开始升级流程时完全冻结代码库。当然，错误修复不在此建议范围内。

停止开发后，建议评估已完成的开发，并将其与当前版本和目标版本之间引入的功能进行对比。尽可能重新审视这些开发，并寻找功能上的变通方案。消除自定义开发与 Odoo 标准版本之间的重复内容，将简化升级流程并减少技术债务。

Note

您可以在 发行说明 中查看版本之间的变更信息。

步骤 2：申请升级后的数据库

在自定义模块的开发停止，并且已实现的功能经过审视以消除冗余和不必要的代码之后，下一步是申请升级后的测试数据库。为此，请根据数据库的托管类型，按照 获取升级后的测试数据库 中所述的步骤操作。

此阶段的目的并不是开始在升级后的数据库中使用自定义模块，而是确保标准升级流程顺利运行，并且测试数据库能够正确交付。如果情况并非如此，且升级请求失败，请通过 支持页面 选择与测试升级相关的选项，向 Odoo 请求协助。

步骤 3：空数据库

在处理升级后的测试数据库之前，我们建议先让自定义开发在目标升级版本的空数据库中正常运行。这样可以确保自定义功能与新版 Odoo 兼容，便于分析其行为以及与新增功能的交互方式，并保证它们在升级数据库时不会引发任何问题。

让自定义模块在空数据库中运行，还有助于避开生产数据库中可能存在的改动和错误配置（例如 Studio 自定义、定制的网站页面、电子邮件模板或翻译）。这些内容与自定义模块本身并无内在关联，可能会在升级流程的这一阶段引发不必要的问题。

要让自定义模块在空数据库中运行，我们建议遵循以下步骤：

1. 使自定义模块可安装

2. 测试与修复

3. 清理代码

4. 使标准测试成功运行

使自定义模块可安装

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

此过程有助于发现在模块安装期间出现的问题。例如：

• 模块依赖关系无效。

• 语法变更：资产声明、OWL 更新、attrs。

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

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

• 方法已重命名或已移除。

• …

测试与修复

安装模块时不再出现回溯后，下一步就是对它们进行测试。即使自定义模块可以安装在空数据库中，也不能保证其执行过程中不会出错。因此，我们建议对所有自定义功能进行全面测试，以确保一切按预期运行。

此过程有助于发现模块安装期间无法识别、只能在运行时检测到的其他问题。例如，对标准 Python 或 OWL 函数的已弃用调用、引用不存在的标准字段等。

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

• 视图

• 电子邮件模板

• 报表

• 服务器动作和自动化动作

• 标准工作流的变更

• 计算字段

我们还建议编写自动化测试，以节省测试迭代的时间、提高测试覆盖率，并确保引入的变更和修复不会破坏现有流程。如果自定义功能中已实现测试，请确保其已升级到新版 Odoo 并能成功运行，同时修复可能存在的问题。

清理代码

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

• 移除冗余和不必要的代码。

• 移除现已属于 Odoo 标准的功能，如 步骤 1：停止开发 中所述。

• 清理不再需要的被注释代码。

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

标准测试

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

如果存在失败的标准测试，我们建议分析其失败原因：

• 自定义功能更改了标准工作流：调整标准测试以适应您的工作流。

• 自定义功能未考虑某种特殊流程：调整自定义功能，以确保其适用于所有标准工作流。

步骤 4：升级后的数据库

当自定义模块可安装并在空数据库中正常运行后，就该让它们在 升级后的数据库 中运行了。

为确保自定义代码在新版本中正常运行，请遵循以下步骤：

• 迁移数据

• 测试自定义模块

迁移数据

在自定义模块的升级过程中，您可能需要使用 升级脚本 将源代码中的变更反映到相应数据中。除了升级脚本，您还可以使用 升级实用工具 及其辅助函数。

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

• 在新版 Odoo 的源代码中以及标准升级过程中从数据库中移除的标准模型数据，如果旧模型表仍然存在，可能需要从该表中恢复。

  Example

  模型 sale.subscription 的自定义字段不会自动从 Odoo 15 迁移到 Odoo 16（当时该模型已合并到 sale.order）。在这种情况下，可以在升级脚本中执行 SQL 查询，将数据从一个表移动到另一个表。请注意，所有列/字段必须已经存在，因此请考虑在 post- 脚本中执行此操作（参见 升级脚本的阶段）。

  Spoiler

  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 OnlineOdoo.shOn-premise

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

测试自定义模块

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

需要注意的事项：

• 视图无法正常工作：在升级过程中，如果某个视图因其内容而出现问题，该视图会被禁用。您可以在升级报告中查看已禁用视图的信息。需要重新激活该视图（如果不再有用则将其删除）。为此，我们建议使用升级脚本。

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

第 5 步：测试与演练

当自定义模块在升级后的数据库中正常工作后，务必再进行一轮测试，以评估数据库的可用性，并发现之前测试中可能被忽略的任何问题。有关测试升级后数据库的更多信息，请参阅 测试新版数据库。

如 升级生产数据库 所述，标准升级脚本和您的数据库都在不断变化。因此，强烈建议经常申请新的升级测试数据库，并确保升级过程仍然成功。

此外，在升级生产数据库的前一天，请完整演练一遍升级过程，以避免升级期间出现意外行为，并发现迁移后的数据可能出现的任何问题。

第 6 步：生产环境升级

当您确信可以升级生产数据库后，请根据数据库的托管类型，按照 升级生产数据库 中描述的流程操作。