乍一看，企业版 databases 模块像是一个“记住其他数据库地址并展示几个 KPI”的后台工具。但从源码看，它更像一套数据库纳管框架：负责远端能力探测、API fallback、本地项目承载、用户映射和批量同步保护。
一、第一步不是同步，而是先判断怎么连
api.py 里 OdooDatabaseApi.fetch_version() 先试 /json/version，失败后再 fallback 到 XML-RPC common.version。后续 fallback_to_xmlrpc 装饰器也说明：JSON2 失败不是任务终止，而是自动降级到 XML-RPC。
这对纳管框架非常关键，因为远端数据库版本、网络环境、接口开放程度都不一致。能不能优雅降级，决定了系统是不是“偶尔可用”还是“多数时候可用”。
二、project.project 在这里承担的是“数据库容器”角色
project_project.py 给项目扩展了 hosting、database_url、api_login、api_key、KPI properties、database_user_ids 等字段。create() 里还会把这类项目默认设成 privacy_visibility = followers，避免随机用户直接看到数据库纳管信息。
这说明 databases 模块并没有再造一个“数据库主表”，而是复用项目模型做承载容器，让数据库同步数据天然挂到项目协作语境里。
三、连接参数不是原样保存，而是会被规范化和分层处理
_normalize_user_url() 会给用户输入补协议；_compute_database_api_key_to_use() 又会根据 hosting 模式决定是用本地 key 还是 Odoo.com 级别 key。也就是说，“一个 URL + 一个 key”看起来简单，实际上源码在替你处理：
- URL 有没有协议；
- SaaS 场景是否应复用平台级 key；
- 某些连接动作该跳到外部链接还是 Odoo.com connect 页面。
四、真正难的是同步写回，不是远端读数
DatabasesSynchronizationWizard._do_synchronize() 先控制 immediate_sync_limit，再分批处理数据库；_write_users() 负责把远端用户和本地 project 下的 databases.user 做差异写回；_write_kpis() 则把 KPI 映射到 properties，同时按配置跳过文档、草稿分录或报税指标。
这说明数据库纳管的复杂度在于：
- 不同库数量很多，不能无脑一次全同步；
- 用户需要增删对齐，而不是只 append；
- KPI 不是简单 key/value，很多还要转成本地 properties 定义。
五、批量同步还有网络侧分组保护
_group_by_ips() 会把数据库 API 按解析出来的 IP 分组。这个细节看似小，实际上非常实战：它避免在批量同步时把同一物理地址背后的多库打成一锅粥，也更利于后续限流和错误归因。
六、新手误区
1. 以为 JSON2 不通就是模块坏了
源码本来就支持回退 XML-RPC，这不是异常路径，而是设计路径。
2. 以为同步用户就是覆盖写一遍
实际需要找 common users、missing logins、待删除用户并分别处理。
3. 以为 project 只是临时 UI 容器
在这个模块里，project 就是数据库治理对象的宿主。
七、实战注意事项
- 纳管前先统一远端 URL 规范，避免协议/域名写法带来重复库；
- 大批量同步时关注 immediate_sync_limit，不要一次把所有库打满；
- 用户映射异常先查 login，而不是先怀疑权限；
- 若 connect 行为跳错页面，先看 hosting 模式与
database_uuid获取是否成功。
结语
企业版 databases 真正解决的问题，不是“帮你记住几个数据库地址”，而是把远端协议差异、本地承载模型、用户/KPI 回写和批量同步守卫组合成一套可运营的数据库纳管框架。
DISCUSSION
评论区