Odoo12 ORM API ☞ Porting from the old API to the new API

本文主要是介绍Odoo12 ORM API ☞ Porting from the old API to the new API，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Porting from the old API to the new API（从旧API移植到新API）

在新API中应避免使用ids列表，而是使用记录集
仍旧使用旧API编写的方法应由ORM自动转换，无需切换到旧API，只需将它们称为新API方法即可
*search()*返回一个记录集，例如查询其结果
fields.related和fields.function由使用带有related = 或compute = 参数的普通字段类型替换
compute= 方法中使用 depends() 必须要完整，它必须列出计算方法使用的所有字段和子字段。depends依赖的字段多点（将在不需要的情况下重新计算字段）比不够了要好（将忘记重新计算字段然后值将不正确）
删除计算字段上的所有onchange方法。当其中一个依赖项发生更改时，计算字段会自动重新计算，并且用于由客户端自动生成onchange
装饰器model()和multi()用于在从旧的API上下文调用时进行转接，对于内部或纯新的api（例如计算），它们是无用的
如果字段的 string= 是字段名称的标题版本：

name = fields.Char(string="Name")

它没用，应该删除

multi = 参数在新API字段上不执行任何操作在相同结果的所有相关字段上使用相同的compute = 方法
按名称（作为字符串）提供compute =，inverse =和search =方法，这使得它们可以被重写（不需要中间的 “trampoline” 函数）
仔细检查所有字段和方法是否有不同的名称，在冲突时没有警告（因为Python在Odoo看到任何东西之前处理它）
正常的new-api导入方式为 from odoo import fields, models. 如果需要兼容性装饰器请使用 from odoo import api, fields, models
避免使用*one()*装饰器，它可能不会达到预期效果
去掉显式定义 create_uid, create_date, write_uid and write_date fields 字段: 它们现在被创建为常规的“合法”字段，并且可以像开箱即用的任何其他字段一样进行读写
当不能直接转换（语义无法桥接）或“旧API”版本不可取，并且可以针对新API进行改进，可以使用v7（）和v8（）为相同的方法名称使用完全不同的“旧API”和“新API”实现。首先应使用旧的API样式定义该方法，并使用v7（）进行修饰，然后应使用完全相同的名称重新定义它，但使用新的API样式并使用v8（）进行修饰。来自旧API上下文的调用将被分派到第一个实现，并且来自新API上下文的调用将被分派到第二个实现。一个实现可以通过切换上下文来调用（并经常），调用另一个实现。

Danger!
使用这些装饰器使得方法极难覆盖并且难以理解和记录

_columns或_all_columns的使用应替换为_fields,它提供了对新式odoo.fields.Field实例（而不是旧式odoo.osv.fields._column）实例的访问。
使用新API样式创建的非存储计算字段在_columns中不可用，只能通过_fields进行检查
在方法中重新分配self可能是不必要的，可能会破坏翻译检查
环境对象依赖于某些threadlocal状态，必须在使用之前进行设置。在尝试在尚未设置的上下文中使用新API时，有必要使用odoo.api.Environment.manage（）上下文管理器，例如新线程或Python交互式环境：

>>> from odoo import api, modules
>>> r = modules.registry.RegistryManager.get('test')
>>> cr = r.cursor()
>>> env = api.Environment(cr, 1, {})
Traceback (most recent call last):...
AttributeError: environments
>>> with api.Environment.manage():
...     env = api.Environment(cr, 1, {})
...     print env['res.partner'].browse(1)
...
res.partner(1,)

Automatic bridging of old API methods(自动桥接旧的API方法)

初始化模型时，如果它们看起来像旧API样式中声明的模型，则会自动扫描和桥接所有方法。这种桥接使它们可以从新的API风格(new-API-style)方法中透明地调用。
如果第二个位置参数（在self之后）为cr或cursor，则方法被匹配为“旧API样式”。系统还识别第三个位置参数为uid或user，第四个为id或id。它还识别出存在任何称为上下文的参数。
从新的API上下文调用此类方法时，系统将自动填充当前Environment（对于cr, user and context）或当前记录集（对于id和ids）的匹配参数。
在极少数情况下，可以通过装饰旧式方法来定制桥接：

通过使用noguess（）完全禁用修饰、修饰方法将没有桥接，并且将从新旧API样式中以完全相同的方式调用方法：
明确定义桥接方法，这主要是针对错误匹配的方法（因为参数以意想不到的方式命名）：

cr()
将在位置自动将当前光标前置到显式提供的参数
cr_uid()
将自动将当前光标和用户的id添加到明确提供的参数中
cr_uid_ids()
将自动将当前光标，用户的id和记录集的id添加到显式提供的参数
cr_uid_id()
将循环遍历当前记录集并为每个记录调用该方法一次，将当前游标，用户的id和记录的id添加到显式提供的参数。
Danger！
从新的API上下文调用时，此包装器的结果始终是一个列表

所有这些方法都有一个_context后缀版本（例如cr_uid_context（）），它也通过关键字传递当前上下文。