升级自定义数据库

升级到 Odoo 的新版本可能会充满挑战，尤其是当您正在处理的数据库包含自定义模块时。本页面旨在解释升级包含自定义模块的数据库的技术流程。有关如何升级不包含自定义模块的数据库的指导，请参阅 升级文档 。

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

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

1. 保持支持

2. 获取最新功能

3. 享受性能改进

4. 减少技术债务

5. 受益于安全性改进

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

以下是升级自定义数据库需要遵循的步骤：

1. 停止开发并对其进行评估 。

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

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

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

5. 进行全面测试并进行演练 。

6. 升级生产数据库 。

步骤 1：停止开发

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

一旦停止开发，评估已进行的开发并与当前版本和目标版本之间引入的功能进行比较是一个良好的实践。尽可能对开发内容提出挑战，并寻找功能上的替代方案。消除您的开发与 Odoo 标准版本之间的冗余将简化升级过程并减少技术债务。

注解

您可以在 发行说明 中找到有关版本之间变更的信息。

步骤 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 在线版数据库中不允许安装包含 Python 文件的自定义模块，因此无法在此平台上运行升级脚本。

测试自定义模块

为了确保自定义模块在升级后的数据库中与您的数据正常工作，也需要对其进行测试。这有助于确保数据库中存储的标准数据和自定义数据一致，并且在升级过程中没有数据丢失。

需要注意的事项：

• 视图无法正常工作：在升级过程中，如果某个视图由于其内容导致问题，它会被禁用。您可以在升级报告中找到被禁用视图的相关信息。该视图需要重新激活（或者如果不再有用则删除）。为此，我们建议使用升级脚本来实现。

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

步骤 5：测试与演练

当自定义模块在升级后的数据库中正常运行时，进行另一轮测试以评估数据库的可用性并检测之前测试中可能未发现的问题至关重要。有关测试升级数据库的更多信息，请查看 测试新版数据库 。

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

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

步骤 6：生产环境升级

一旦您对升级生产数据库充满信心，请根据数据库的托管类型，遵循 升级生产数据库 中描述的流程。